Systems and methods for smart harq for wifi

ABSTRACT

Systems, methods, and instrumentalities are provided to implement a method of communicating a feedback in a wireless local area network (WLAN). A WLAN device may receive a data frame with a hybrid automatic repeat request (HARQ) data indicator in a frame header. The WLAN device may send an acknowledgement frame when the data frame is correctly received and decoded. The WLAN device may send a negative acknowledgement frame when the data frame is not correctly received and decoded.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/713,795 filed Dec. 13, 2019, which issued as U.S. Pat. No. 11,228,401on Jan. 18, 2022, which is a continuation of U.S. patent applicationSer. No. 14/903,620, filed Jan. 8, 2016, which is a 371 application ofInternational Application No. PCT/US14/46274, filed Jul. 11, 2014, whichclaims the benefit of U.S. Provisional Patent Application No.61/845,092, filed on Jul. 11, 2013 and U.S. Provisional PatentApplication No. 61/845,101, filed on Jul. 11, 2013, the disclosures ofwhich are hereby incorporated by reference in their entirety.

BACKGROUND

WiFi enabled devices, e.g., laptop computers, tablet computers, personaldigital assistant devices, mobile or cellular phones, smart televisionsets, set top boxes, personal media players, etc., that may communicateusing WiFi signals are becoming increasingly popular. Several emergingWiFi communications standards (e.g., 802.11ac, 802.11ad, etc.) have beendeveloped and are being developed for facilitating communication of suchWiFi enabled devices in a Wireless Local Area Network (WLAN). The errorcontrol mechanisms provided by the available WiFi communicationstandards may be inadequate.

SUMMARY

Systems, methods, and instrumentalities associated with datatransmissions are disclosed. Devices, such as 802.11 devices, may beconfigured to use ACK/NACK information relating to data transmissions.Such data transmissions may be part of an 802.11 exchange (e.g., a speedframe exchange, a bi-directional TXOP, etc.). A first station (STA) mayreceive a first transmission from a second STA. The first transmissionmay comprise first data. The first STA may determine whether or not thefirst data was received correctly and send a second transmission to thesecond STA that includes combined information that may comprise its owndata and an ACK/NACK indication associated with the first data. Forexample, the combined information may be a packet that includes a datapart (e.g., second data) and an ACK/NACK part associated with the firstdata. When the first STA determines that the first data was receivedcorrectly, the combined information comprises the data part and an ACK.When the first STA determines that the first data was not receivedcorrectly, the combined information comprises the data part and a NACK.In the case of a NACK, the combined information may include a framecomprising a type field and a subtype field. A value of the type fieldand/or a value of the subtype field may be set to indicate the NACK.

Data transmissions by stations may include an indication of how manytimes data has been sent. For example, if data is being sent for thefirst time, the indication may indicate an initial transmission (e.g.,TX1). If data is being sent for a second time (e.g., there was a NACKassociated with the first sending, no HARQ feedback received relating tothe first sending, etc.), the indication may indicate that it is thesecond time the data is being sent (e.g., TX2). After data is sent afirst time, a redundancy version(s) may subsequently be used whensending the data.

A fault recovery operation may be used in combination with HARQ. Astation may send data (e.g., a data packet, a combined data/ACK/NACKpacket, etc.). A counter associated with the data (e.g., and associatedHARQ process) may be started. When an ACK or NACK has not been receivedbefore the counter expires, the station may retransmit the sent data.For example, the station may resend the data transmission (e.g., if thetransmission was the first transmission, the first transmission may beresent; if the transmission was a subsequent transmission where aredundancy version was sent, the redundancy version may be resent, ordifferent redundancy version may be sent; etc.).

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A depicts an exemplary communications system.

FIG. 1B depicts an exemplary wireless transmit/receive unit (WTRU).

FIG. 1C depicts exemplary wireless local area network (WLAN) devices.

FIG. 1D depicts an exemplary WLAN system.

FIG. 2 depicts an exemplary Hybrid Automatic Repeat reQuest (HARQ)capability Information Element (IE).

FIG. 3 depicts an exemplary HARQ Operation IE.

FIG. 4 depicts an exemplary negative acknowledgement (NACK) frame.

FIG. 5 depicts an exemplary Block Acknowledgement (BA) frame.

FIG. 6 depicts an exemplary BA Control Field setting to indicate a NACKframe.

FIG. 7 depicts an exemplary HARQ operation using Speed Frame Exchange.

FIG. 8 depicts an exemplary HARQ operation using the multi-frametransmission opportunity (TXOP).

FIG. 9 depicts an exemplary scheduled HARQ.

FIG. 10 depicts an exemplary scheduled multiple stop and wait (MSOW)HARQ operation.

FIG. 11 depicts an exemplary MSOW HARQ process using aggregated packets.

FIG. 12 depicts an exemplary MAC header with a cyclic redundancy check(CRC) field.

FIG. 13 depicts an exemplary Space Time Block Coding (STBC) mapping forHARQ transmissions.

FIG. 14 depicts an exemplary Physical Layer Service Data Unit (PSDU)aggregation supporting HARQ.

FIG. 15 depicts an exemplary aggregated PSDU (A-PSDU) SIG field.

FIG. 16 depicts an exemplary HARQ retransmission with partiallow-density parity check (LDPC) code words.

DETAILED DESCRIPTION

A detailed description of illustrative embodiments will now be describedwith reference to the various figures. Although this descriptionprovides a detailed example of possible implementations, it should benoted that the details are intended to be exemplary and in no way limitthe scope of the application.

FIG. 1A is a diagram of an example communications system 100 in whichone or more disclosed features may be implemented. For example, awireless network (e.g., a wireless network comprising one or morecomponents of the communications system 100) may be configured such thatbearers that extend beyond the wireless network (e.g., beyond a walledgarden associated with the wireless network) may be assigned QoScharacteristics.

The communications system 100 may be a multiple access system thatprovides content, such as voice, data, video, messaging, broadcast,etc., to multiple wireless users. The communications system 100 mayenable multiple wireless users to access such content through thesharing of system resources, including wireless bandwidth. For example,the communications systems 100 may employ one or more channel accessmethods, such as code division multiple access (CDMA), time divisionmultiple access (TDMA), frequency division multiple access (FDMA),orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like.

As shown in FIG. 1A, the communications system 100 may include at leastone wireless transmit/receive unit (WTRU), such as a plurality of WTRUs,for instance WTRUs 102 a, 102 b, 102 c, and 102 d, a radio accessnetwork (RAN) 104, a core network 106, a public switched telephonenetwork (PSTN) 108, the Internet 110, and other networks 112, though itshould be appreciated that the disclosed embodiments contemplate anynumber of WTRUs, base stations, networks, and/or network elements. Eachof the WTRUs 102 a, 102 b, 102 c, 102 d may be any type of deviceconfigured to operate and/or communicate in a wireless environment. Byway of example, the WTRUs 102 a, 102 b, 102 c, 102 d may be configuredto transmit and/or receive wireless signals and may include userequipment (UE), a mobile station, a fixed or mobile subscriber unit, apager, a cellular telephone, a personal digital assistant (PDA), asmartphone, a laptop, a netbook, a personal computer, a wireless sensor,consumer electronics, and the like.

The communications systems 100 may also include a base station 114 a anda base station 114 b. Each of the base stations 114 a, 114 b may be anytype of device configured to wirelessly interface with at least one ofthe WTRUs 102 a, 102 b, 102 c, 102 d to facilitate access to one or morecommunication networks, such as the core network 106, the Internet 110,and/or the networks 112. By way of example, the base stations 114 a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a HomeNode B, a Home eNode B, a site controller, an access point (AP), awireless router, and the like. While the base stations 114 a, 114 b areeach depicted as a single element, it should be appreciated that thebase stations 114 a, 114 b may include any number of interconnected basestations and/or network elements.

The base station 114 a may be part of the RAN 104, which may alsoinclude other base stations and/or network elements (not shown), such asa base station controller (BSC), a radio network controller (RNC), relaynodes, etc. The base station 114 a and/or the base station 114 b may beconfigured to transmit and/or receive wireless signals within aparticular geographic region, which may be referred to as a cell (notshown). The cell may further be divided into cell sectors. For example,the cell associated with the base station 114 a may be divided intothree sectors. Thus, in one embodiment, the base station 114 a mayinclude three transceivers, i.e., one for each sector of the cell. Inanother embodiment, the base station 114 a may employ multiple-inputmultiple output (MIMO) technology and, therefore, may utilize multipletransceivers for each sector of the cell.

The base stations 114 a, 114 b may communicate with one or more of theWTRUs 102 a, 102 b, 102 c, 102 d over an air interface 116, which may beany suitable wireless communication link (e.g., radio frequency (RF),microwave, infrared (IR), ultraviolet (UV), visible light, etc.). Theair interface 116 may be established using any suitable radio accesstechnology (RAT).

More specifically, as noted above, the communications system 100 may bea multiple access system and may employ one or more channel accessschemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. Forexample, the base station 114 a in the RAN 104 and the WTRUs 102 a, 102b, 102 c may implement a radio technology such as Universal MobileTelecommunications System (UMTS) Terrestrial Radio Access (UTRA), whichmay establish the air interface 116 using wideband CDMA (WCDMA). WCDMAmay include communication protocols such as High-Speed Packet Access(HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed DownlinkPacket Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

In another embodiment, the base station 114 a and the WTRUs 102 a, 102b, 102 c may implement a radio technology such as Evolved UMTSTerrestrial Radio Access (E-UTRA), which may establish the air interface116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

In other embodiments, the base station 114 a and the WTRUs 102 a, 102 b,102 c may implement radio technologies such as IEEE 802.16 (i.e.,Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000,CDMA2000 1×, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), InterimStandard 95 (IS-95), Interim Standard 856 (IS-856), Global System forMobile communications (GSM), Enhanced Data rates for GSM Evolution(EDGE), GSM EDGE (GERAN), and the like.

The base station 114 b in FIG. 1A may be a wireless router, Home Node B,Home eNode B, or access point, for example, and may utilize any suitableRAT for facilitating wireless connectivity in a localized area, such asa place of business, a home, a vehicle, a campus, and the like. In oneembodiment, the base station 114 b and the WTRUs 102 c, 102 d mayimplement a radio technology such as IEEE 802.11 to establish a wirelesslocal area network (WLAN). In another embodiment, the base station 114 band the WTRUs 102 c, 102 d may implement a radio technology such as IEEE802.15 to establish a wireless personal area network (WPAN). In yetanother embodiment, the base station 114 b and the WTRUs 102 c, 102 dmay utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE,LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A,the base station 114 b may have a direct connection to the Internet 110.Thus, the base station 114 b may not be required to access the Internet110 via the core network 106.

The RAN 104 may be in communication with the core network 106, which maybe any type of network configured to provide voice, data, applications,and/or voice over internet protocol (VoIP) services to one or more ofthe WTRUs 102 a, 102 b, 102 c, 102 d. For example, the core network 106may provide call control, billing services, mobile location-basedservices, pre-paid calling, Internet connectivity, video distribution,etc., and/or perform high-level security functions, such as userauthentication. Although not shown in FIG. 1A, it should be appreciatedthat the RAN 104 and/or the core network 106 may be in direct orindirect communication with other RANs that employ the same RAT as theRAN 104 or a different RAT. For example, in addition to being connectedto the RAN 104, which may be utilizing an E-UTRA radio technology, thecore network 106 may also be in communication with another RAN (notshown) employing a GSM radio technology.

The core network 106 may also serve as a gateway for the WTRUs 102 a,102 b, 102 c, 102 d to access the PSTN 108, the Internet 110, and/orother networks 112. The PSTN 108 may include circuit-switched telephonenetworks that provide plain old telephone service (POTS). The Internet110 may include a global system of interconnected computer networks anddevices that use common communication protocols, such as thetransmission control protocol (TCP), user datagram protocol (UDP) andthe internet protocol (IP) in the TCP/IP internet protocol suite. Thenetworks 112 may include wired or wireless communications networks ownedand/or operated by other service providers. For example, the networks112 may include another core network connected to one or more RANs,which may employ the same RAT as the RAN 104 or a different RAT.

Some or all of the WTRUs 102 a, 102 b, 102 c, 102 d in thecommunications system 100 may include multi-mode capabilities, i.e., theWTRUs 102 a, 102 b, 102 c, 102 d may include multiple transceivers forcommunicating with different wireless networks over different wirelesslinks. For example, the WTRU 102 c shown in FIG. 1A may be configured tocommunicate with the base station 114 a, which may employ acellular-based radio technology, and with the base station 114 b, whichmay employ an IEEE 802 radio technology.

FIG. 1B depicts an exemplary wireless transmit/receive unit, WTRU 102.WTRU 102 may be used in one or more of the communications systemsdescribed herein. As shown in FIG. 1B, the WTRU 102 may include aprocessor 118, a transceiver 120, a transmit/receive element 122, aspeaker/microphone 124, a keypad 126, a display/touchpad 128,non-removable memory 130, removable memory 132, a power source 134, aglobal positioning system (GPS) chipset 136, and other peripherals 138.It should be appreciated that the WTRU 102 may include anysub-combination of the foregoing elements while remaining consistentwith an embodiment.

The processor 118 may be a general purpose processor, a special purposeprocessor, a conventional processor, a digital signal processor (DSP), aplurality of microprocessors, one or more microprocessors in associationwith a DSP core, a controller, a microcontroller, Application SpecificIntegrated Circuits (ASICs), Field Programmable Gate Array (FPGAs)circuits, any other type of integrated circuit (IC), a state machine,and the like. The processor 118 may perform signal coding, dataprocessing, power control, input/output processing, and/or any otherfunctionality that enables the WTRU 102 to operate in a wirelessenvironment. The processor 118 may be coupled to the transceiver 120,which may be coupled to the transmit/receive element 122. While FIG. 1Bdepicts the processor 118 and the transceiver 120 as separatecomponents, it should be appreciated that the processor 118 and thetransceiver 120 may be integrated together in an electronic package orchip.

The transmit/receive element 122 may be configured to transmit signalsto, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, thetransmit/receive element 122 may be an antenna configured to transmitand/or receive RF signals. In another embodiment, the transmit/receiveelement 122 may be an emitter/detector configured to transmit and/orreceive IR, UV, or visible light signals, for example. In yet anotherembodiment, the transmit/receive element 122 may be configured totransmit and receive both RF and light signals. It should be appreciatedthat the transmit/receive element 122 may be configured to transmitand/or receive any combination of wireless signals.

In addition, although the transmit/receive element 122 is depicted inFIG. 1B as a single element, the WTRU 102 may include any number oftransmit/receive elements 122. More specifically, the WTRU 102 mayemploy MIMO technology. Thus, in one embodiment, the WTRU 102 mayinclude two or more transmit/receive elements 122 (e.g., multipleantennas) for transmitting and receiving wireless signals over the airinterface 116.

The transceiver 120 may be configured to modulate the signals that areto be transmitted by the transmit/receive element 122 and to demodulatethe signals that are received by the transmit/receive element 122. Asnoted above, the WTRU 102 may have multi-mode capabilities. Thus, thetransceiver 120 may include multiple transceivers for enabling the WTRU102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, forexample.

The processor 118 of the WTRU 102 may be coupled to, and may receiveuser input data from, the speaker/microphone 124, the keypad 126, and/orthe display/touchpad 128 (e.g., a liquid crystal display (LCD) displayunit or organic light-emitting diode (OLED) display unit). The processor118 may also output user data to the speaker/microphone 124, the keypad126, and/or the display/touchpad 128. In addition, the processor 118 mayaccess information from, and store data in, any type of suitable memory,such as the non-removable memory 130 and/or the removable memory 132.The non-removable memory 130 may include random-access memory (RAM),read-only memory (ROM), a hard disk, or any other type of memory storagedevice. The removable memory 132 may include a subscriber identitymodule (SIM) card, a memory stick, a secure digital (SD) memory card,and the like. In other embodiments, the processor 118 may accessinformation from, and store data in, memory that is not physicallylocated on the WTRU 102, such as on a server or a home computer (notshown).

The processor 118 may receive power from the power source 134, and maybe configured to distribute and/or control the power to the othercomponents in the WTRU 102. The power source 134 may be any suitabledevice for powering the WTRU 102. For example, the power source 134 mayinclude one or more dry cell batteries (e.g., nickel-cadmium (NiCd),nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion),etc.), solar cells, fuel cells, and the like.

The processor 118 may also be coupled to the GPS chipset 136, which maybe configured to provide location information (e.g., longitude andlatitude) regarding the current location of the WTRU 102. In additionto, or in lieu of, the information from the GPS chipset 136, the WTRU102 may receive location information over the air interface 116 from abase station (e.g., base stations 114 a, 114 b) and/or determine itslocation based on the timing of the signals being received from two ormore nearby base stations. It should be appreciated that the WTRU 102may acquire location information by way of any suitablelocation-determination method while remaining consistent with anembodiment.

The processor 118 may further be coupled to other peripherals 138, whichmay include one or more software and/or hardware modules that provideadditional features, functionality and/or wired or wirelessconnectivity. For example, the peripherals 138 may include anaccelerometer, an e-compass, a satellite transceiver, a digital camera(for photographs or video), a universal serial bus (USB) port, avibration device, a television transceiver, a hands free headset, aBluetooth© module, a frequency modulated (FM) radio unit, a digitalmusic player, a media player, a video game player module, an Internetbrowser, and the like.

FIG. 1C depicts exemplary WLAN devices, one or more of which may be usedto implement one or more of the features described herein, operating ina WLAN system 200. The WLAN system 200 may be configured to implementone or more protocols of the IEEE 802.11 communication standard, whichmay include a channel access scheme, such as DSSS, OFDM, OFDMA, etc. AWLAN may operate in a mode, e.g., an infrastructure mode, an ad-hocmode, etc.

The WLAN system 200 may include, but is not limited to, an access point(AP) 202, a station (STA) 204, and STA 206. The STA 204 and STA 206 maybe associated with the AP 202. A WLAN operating in an infrastructuremode may comprise one or more APs communicating with one or moreassociated STAs. An AP and STA(s) associated with the AP may comprise abasic service set (BSS). For example, AP 202, STA 204, and STA 206 maycomprise BSS 210. An extended service set (ESS) may comprise one or moreAPs (with one or more BSSs) and STA(s) associated with the APs.

An AP may have access to, and/or interface to, a distribution system(DS), which may be wired and/or wireless and may carry traffic to and/orfrom the AP. Traffic to a STA in the WLAN originating from outside theWLAN may be received at an AP in the WLAN, which may send the traffic tothe STA in the WLAN. Traffic originating from a STA in the WLAN to adestination outside the WLAN may be sent to an AP in the WLAN, which maysend the traffic to the destination.

As depicted, the AP 202 is in communication with a network 220. Thenetwork 220 is in communication with a server 230. Traffic between STAswithin the WLAN may be sent through one or more APs. For example, asource STA (e.g., STA 206) may have traffic intended for a destinationSTA (e.g., STA 204). STA 206 may send the traffic to AP 202, and, AP 202may send the traffic to STA 204.

A WLAN may operate in an ad-hoc mode. The ad-hoc mode WLAN may bereferred to as independent BSS. In an ad-hoc mode WLAN, the STAs maycommunicate directly with each other (e.g., STA 204 may communicate withSTA 206 without such communication being routed through an AP).

IEEE 802.11 devices (e.g., IEEE 802.11 APs in a BSS) may use beaconframes to announce the existence of a WLAN network. An AP, such as AP202, may transmit a beacon on a channel, e.g., a fixed channel, such asa primary channel. A STA may use a channel, such as the primary channel,to establish a connection with an AP.

STA(s) and/or AP(s) may use a Carrier Sense Multiple Access withCollision Avoidance (CSMA/CA) channel access mechanism. In CSMA/CA, aSTA and/or an AP may sense the primary channel. For example, if a STAhas data to send, the STA may sense the primary channel. If the primarychannel is detected to be busy, the STA may back off. For example, aWLAN or portion thereof may be configured so that one STA may transmitat a given time, e.g., in a given BSS. Channel access may include RTSand/or CTS signaling. For example, an exchange of a request to send(RTS) frame may be transmitted by a sending device and a clear to send(CTS) frame that may be sent by a receiving device. For example, if anAP has data to send to a STA, the AP may send an RTS frame to the STA.If the STA is ready to receive data, the STA may respond with a CTSframe. The CTS frame may include a time value that may alert other STAsto hold off from accessing the medium while the AP initiating the RTSmay transmit its data. On receiving the CTS frame from the STA, the APmay send the data to the STA.

A device may reserve spectrum, e.g., via virtual CCA by using a networkallocation vector (NAV). For example, in an IEEE 802.11 frame, theDuration field may be used to reserve a channel for a time period. A STAreceiving the frame may set its NAV to the value in the Duration fieldof the frame. A STA may reserve the medium for the time for which it mayexpect to use the channel. When a STA reserves the medium, the NAV maybe set for an associated WLAN or subset thereof (e.g., a BSS). OtherSTAs may count down the NAV to zero. When the counter reaches a value ofzero, the NAV functionality may indicate to the STA that the channel isnow free of medium reservation.

The devices in a WLAN, such as an AP or STA, may include one or more ofthe following: a processor, a memory, a radio receiver, and/ortransmitter (e.g., which may be combined in a transceiver), one or moreantennas, etc. A processor function may comprise one or more processors.For example, the processor may comprise one or more of: a generalpurpose processor, a special purpose processor (e.g., a basebandprocessor, a MAC processor, etc.), a digital signal processor (DSP),Application Specific Integrated Circuits (ASICs), Field ProgrammableGate Array (FPGAs) circuits, any other type of integrated circuit (IC),a state machine, and the like. The one or more processors may beintegrated or not integrated with each other. The processor (e.g., theone or more processors or a subset thereof) may be integrated with oneor more other functions (e.g., other functions such as memory). Theprocessor may perform signal coding, data processing, power control,input/output processing, modulation, demodulation, and/or any otherfunctionality that may enable the device to operate in a wirelessenvironment, such as the WLAN of FIG. 1D. The processor may beconfigured to execute processor executable code (e.g., instructions)including, for example, software and/or firmware instructions. Forexample, the processer may be configured to execute computer readableinstructions included on one or more of the processor (e.g., a chipsetthat includes memory and a processor) or memory. Execution of theinstructions may cause the device to perform one or more of thefunctions described herein.

A device may include one or more antennas. The device may employmultiple input multiple output (MIMO) techniques. The one or moreantennas may receive a radio signal. The processor may receive the radiosignal, e.g., via the one or more antennas. The one or more antennas maytransmit a radio signal (e.g., based on a signal sent from theprocessor).

The device may have a memory that may include one or more devices forstoring programming and/or data, such as processor executable code orinstructions (e.g., software, firmware, etc.), electronic data,databases, or other digital information. The memory may include one ormore memory units. One or more memory units may be integrated with oneor more other functions (e.g., other functions included in the device,such as the processor). The memory may include a read-only memory (ROM)(e.g., erasable programmable read only memory (EPROM), electricallyerasable programmable read only memory (EEPROM), etc.), random accessmemory (RAM), magnetic disk storage media, optical storage media, flashmemory devices, and/or other non-transitory computer-readable media forstoring information. The memory may be coupled to the processer. Theprocesser may communicate with one or more entities of memory, e.g., viaa system bus, directly, etc.

Turning to FIG. 1D, a WLAN in infrastructure basic service set (BSS)mode may have an access point (AP) for the basic service set and one ormore stations (STAs) associated with the AP. The AP may have access orinterface to a distribution system (DS) or another type ofwired/wireless network that may carry traffic in and out of the BSS.Traffic to STAs may originate from outside the BSS, may arrive throughthe AP and may be delivered to the STAs. The traffic originating fromSTAs to destinations outside the BSS may be sent to the AP to bedelivered to the respective destinations. Traffic between STAs withinthe BSS may be sent through the AP where the source STA may sendstraffic to the AP and the AP may deliver the traffic to the destinationSTA. The traffic between STAs within a BSS may be peer-to-peer traffic.Such peer-to-peer traffic may be sent directly between the source anddestination STAs, e.g., with a direct link setup (DLS) using an IEEE802.11e DLS or an IEEE 802.11z tunneled DLS (TDLS). A WLAN using anindependent BSS mode may have no APs, and the STAs may communicatedirectly with each other. This mode of communication may be an ad-hocmode.

Using the IEEE 802.11 infrastructure mode of operation, the AP maytransmit a beacon on a fixed channel, usually the primary channel. Thischannel may be 20 MHz wide, and may be the operating channel of the BSS.This channel may also be used by the STAs to establish a connection withthe AP. The channel access in an IEEE 802.11 system may be Carrier SenseMultiple Access with Collision Avoidance (CSMA/CA). In this mode ofoperation, the STAs, including the AP, may sense the primary channel. Ifthe channel is detected to be busy, the STA may back off.

In IEEE 802.11ac, very high throughput (VHT) STAs may support, e.g., 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels. The 40 MHz, and 80MHz channels may be formed, e.g., by combining contiguous 20 MHzchannels. A160 MHz channel may be formed, for example, by combiningeight contiguous 20 MHz channels, or by combining two non-contiguous 80MHz channels (e.g., referred to as an 80+80 configuration). For the80+80 configuration, the data, after channel encoding, may be passedthrough a segment parser that may divide it into two streams. Inversefast Fourier transform (IFFT), and time domain, processing may be doneon each stream separately. The streams may be mapped on to the twochannels, and the data may be transmitted. At the receiver, thismechanism may be reversed, and the combined data may be sent to the MAC.

Hybrid Automatic Repeat reQuest (HARQ) may provide transmission errorcontrol in wireless communication networks, which may rely on errorcorrection codes and/or retransmissions. The types of HARQ combiningschemes may include, e.g., Chase Combining (CC) HARQ, IncrementalRedundancy (IR) HARQ, etc. In CC HARQ, each retransmission may includethe same data and parity bits. A receiver may use Maximum RatioCombining (MRC) to combine the received packet with previoustransmission(s). CC may provide repetition coding, where eachretransmission may increase the Eb/NO at the receiver. In IR HARQ, eachretransmission may use a different set of coded bits (e.g., one or moreredundancy versions of coded bits may be generated by puncturing theencoder output). For turbo code different systematic and parity bits maybe used. At each retransmission, the receiver may gain extrainformation. IR HARQ retransmission may include parity bits or theretransmission may be self-decodable.

HARQ schemes may be synchronous and/or asynchronous. The retransmissionsin each of the HARQ schemes may be adaptive and/or non-adaptive. Forsynchronous HARQ, retransmission for each process may occur atpredefined times, e.g., relative to the initial transmission. The HARQprocess ID may be inferred from retransmission timing. For asynchronousHARQ, retransmissions may occur at any time, e.g., relative to theinitial transmission. Signaling (e.g., explicit signaling) may beutilized to indicate the HARQ process ID. The HARQ process ID may beindicated for the receiver to associate each retransmission with thecorresponding previous transmission.

The HARQ entity may be located in the MAC layer. The HARQ entity may beresponsible for transmit and receive HARQ operations. The transmit HARQoperation may include transmission and retransmission of transportblocks, and reception and processing of acknowledgement (ACK)/negativeacknowledgement (NACK) signaling. The receive HARQ operation may includereception of transport blocks, combining of the received data, andgeneration of ACK/NACK signaling based on decoding results. For example,up to eight HARQ processes in parallel may be used to supportmultiprocess Stop-And-Wait (SAW) HARQ operation, e.g., to enablecontinuous transmission while previous transport blocks may be decoded.Multiprocess HARQ may interlace one or more independent SAW processes intime, for example, so that each of the transmission resources may beused by one or more of the processes. Each HARQ process may beresponsible for a separate SAW operation and may manage a separatebuffer. Asynchronous adaptive HARQ may be used in the downlink andsynchronous (e.g., adaptive and/or non-adaptive) HARQ may be used in theuplink. Signals which may be used to support HARQ may include, forexample, HARQ process ID (e.g., for an asynchronous HARQ), New DataIndicator (NDI), Redundancy Version of the transmission block (RV)(e.g., for adaptive HARQ), or modulation and coding scheme (MCS) (e.g.,for adaptive HARQ), etc. When a packet transmission (e.g., new packettransmission) begins, the NDI may be toggled.

In wireless communication networks, HARQ may provide error control. HARQmay rely on a combination of error correction codes and retransmissions.HARQ may be used in WiFi (e.g., High Efficiency WLAN (HEW), WirelessNext Generation (WNG), 802.11AX, etc.) to increase per link robustnessand per link throughput for a WiFi system. For WiFi HARQ, HARQ signalingand/or HARQ signaling procedures may provide parameters and feedbackbetween the HARQ transmitting STAs, receiving STAs, and/or unintendedreceiving STAs. MAC designs and procedures (e.g., current MAC designsand procedures) for WiFi are not capable of supporting HARQ operations.To enable WiFi HARQ operations, MAC designs may provide support for HARQtransmission and/or retransmission, reception, and ACK/NACK feedback. Tosupport HARQ operations, service primitives may include parameters(e.g., new parameters) and may control HARQ processes. Systems, methods,and instrumentalities may be disclosed to enable HARQ operations inWiFi, which may include cross-layer features.

HARQ parameters and signaling and procedures may be provided. An accesspoint (AP) or a station (STA) may include a HARQ Capability Indicationin a NDP, a management, a control, or an extension frame, e.g., abeacon, a short beacon, a probe request and/or response, associationrequest and/or response frames, etc. The HARQ Capability Indication maybe implemented as a HARQ Capability Information Element (IE).

FIG. 2 illustrates an example design of HARQ Capability IE. The HARQCapability IE may have one or more fields including, e.g., an Element IDfield, a Length field, an HARQ Capabilities field, an HARQ Mode field, aRetry MCS mode field, an RV Modes field, a Concurrent HARQ Processfield, an HARQ Coding field, etc. The HARQ Capability Element mayinclude one or more of the following.

An ID in the Element ID field may identify that the IE may be a HARQCapability Element. The Length field may indicate the length of the HARQCapability Element. The HARQ Capabilities field may indicate the HARQcapabilities of the transmitting STA. The HARQ Capabilities field mayindicate whether the transmitting STA may support HARQ operations, andwhat HARQ types (e.g., Chase Combining (CC), or Incremental Redundancy(IR)) may be supported. The HARQ Capabilities field may be a bitmap,where each bit may be associated with a supported mode. The HARQCapabilities field may be implemented as an integer. A value of thefield may indicate whether one or more of CC, and/or IR HARQ may besupported. The HARQ Capabilities field may be implemented as one bitindicator to indicate whether the transmitting STA supports HARQ.

The HARQ Mode field may indicate how an initial HARQ packet and asubsequent retransmission may be sent. The HARQ transmissions andretransmissions may be scheduled, unscheduled, contiguous, and/ornon-contiguous. For example, an initial HARQ and a retransmissions(e.g., subsequent retransmissions) may be sent using one or more ofscheduled slots, intervals, or beacon (sub)intervals, including, forexample, Power Save Multi-Poll (PSMP) slots, Scheduled Automatic PowerSave Delivery (S-APSD) slots, restricted access window (RAW)slots/Target Wake Time (TWT), Periodic RAW (PRAW), HARQ Slots, Periodicintervals, etc. In case of unscheduled transmission and/orretransmissions, an initial HARQ and a subsequent retransmission may besent using one or more of the medium access schemes including, forexample, within one multi-packet transmit opportunity (TXOP), speedFrame Exchange, Unscheduled Automatic Power Save Delivery (U-APSD)slots, hybrid coordination function (HCF) controlled channel access(HCCA) Poll, Polled by AP, ACK/NACK feedback polled by AP, in multipleTXOP, non-periodic intervals, etc.

The HARQ initial and subsequent retransmissions, and/or ACK/NACKfeedback, may be transmitted in a contiguous approach, e.g., if atransmitting STA is transmitting a HARQ packet, it may continue the HARQretransmissions when the transmitting STA may have access to the medium(e.g., within the same TXOP or in a sequence of TXOP), until the packetmay be correctly received, or until the maximal retry may be reached.

In non-contiguous approach, the sequence of the HARQ initial andsubsequent retransmissions, and/or ACK/NACK feedback, may be interruptedor interlaced by transmission of other packets by the same transmittingSTA. For example, this mode may be used for multiple stop and wait HARQprocess to allow a number of concurrent HARQ processes each for adifferent packet, or block of data. In another example, this mode may beused to allow transmissions of regular (non-HARQ) packets to beinterlaced within HARQ initial and subsequent retransmissions and/orACK/NACK feedback sequences.

The Retry Modulation and Coding Scheme (MCS) Mode field may indicate themode of using MCS in an initial transmission and one or more subsequentretransmissions. The Retry MCS field may be specified for a HARQprocess, and/or may be used to specify for transmission andretransmission (e.g., retries) of regular (e.g., non-HARQ) packets. TheMCS mode may include, e.g., same MCS, adaptive MCS, unequal MCS, etc.The same MCS may be used for the initial and retries of thetransmissions of a given (e.g., HARQ and/or non-HARQ) packet. Adifferent MCS (e.g., an adaptive MCS) may be used for the initial andretries of the transmissions of a given (e.g., HARQ and/or non-HARQ)packet. Unequal MCS may be used for different MIMO streams and/orantennas.

The RV Modes field may provide RV related information of the HARQprocess. If the HARQ type is not IR, the RV Modes field may be omittedor is empty or set to “0”. The RV Modes field may provide the number ofRVs a transmitting STA may support when conducting the HARQ procedure.The RV Modes field may provide implicit RV transmission order. Atransmitting STA may transmit one or more different RVs. For example,the RVs may be transmitted in a pre-determined order, such as RV0, RV2,RV1, and RV3. The RV Modes field may provide RV indication (e.g.,explicit indication) to specify whether explicit RV indication needs tobe provided. If the RV Indication subfield is set, a transmitting STA ofa HARQ frame using IR may indicate (e.g., explicitly) the version of theRV in the HARQ frame, e.g., in the Physical Layer Convergence Protocol(PLCP) and/or MAC header.

The Concurrent HARQ Process field may specify the number of concurrentHARQ processes that the transmitting STA may support, e.g., whenconducting the HARQ procedure. The HARQ Encoding field may specify theencoding scheme that may be used when encoding an HARQ packet, e.g.,Block Convolutional Code (BCC), low-density parity check code (LDP),turbo code, etc. The information about the LDPC and/or Turbo IterationCounts may be added as parameters (e.g., recommended and/or mandatoryparameters).

An AP may transmit an HARQ Operation IE, which may specify HARQoperations and parameters. The HARQ Operation IE may be transmitted in aNDP, a management, a control, and/or an extension frame, e.g., a beaconframe, a short beacon frame, a probe response frame, an associationresponse frame, etc.

FIG. 3 illustrates an example of an HARQ Operation IE. The HARQoperation IE may have one or more of the following exemplary fields: anElement ID field, a length field, a HARQ Type Used field, a HARQ Modefield, a Retry MCS Mode field, a RV modes field, a Concurrent HARQProcess field, or an HARQ Coding field.

The ID in the Element ID field may identify that the information elementis an HARQ Operation IE. A Length field may indicate the length of theHARQ Operation IE. A HARQ Type Used field may indicate the HARQ Type(s)that may be used for HARQ operation in a BSS (e.g., current BSS), suchas Chase Combining (CC), and/or Incremental Redundancy (IR). This fieldmay be implemented as a bitmap. Each bit of the bitmap may be associatedwith a supported mode. In this field an integer value may indicate thesupport of one or both of CC or IR. The remaining fields of the HARQOperation IE may be similar to the corresponding fields of the HARQCapability IE. These fields may be used to indicate the HARQ operationsand the HARQ parameters being used in a BSS (e.g., current BSS).

HARQ Capability indication may be provided. For example,dot11HARQActivated parameter may be used to indicate that an STA and/oran AP is capable of HARQ. If dot11HARQActivated is true, an AP and/or anSTA may include an indication of HARQ support in the VHT/S1G/HEWNHSECapabilities field. The Capabilities field may be signaled in framesincluding, for example, a beacon frame, a short beacon frame, a proberequest and/or a probe response frame, an association request and/or anassociation response frame, or a NDP, a management frame, a control, anextension frames, etc. Such an indication may be provided using one bit.When the bit is set to 1, HARQ may be supported by the AP and/or STA. Asetting of the HARQ Supported indication in the VHT/S1G/HEWNHSECapabilities field may imply that a HARQ Capability IE is included inthe same packet or in a different packet, such as a beacon frame. If thedot11HARQActivated is true, an AP/STA may include a HARQ Capability IEin a beacon frame, a short beacon frame, a probe request and/or a proberesponse frame, an association request and/or an association responseframe, or a NDP, a management frame, a control, an extension frames,etc. The inclusion of the HARQ Capability IE may be an indication thatHARQ may be supported by the transmitting STA.

If dot11HARQActivated is true, an AP may include a HARQ Operation IE ina beacon frame, a short beacon frame, a probe request and/or a proberesponse frame, an association request and/or an association responseframe, or a NDP, a management frame, a control, an extension frames tospecify the HARQ operations and parameters used in a BSS (e.g., thecurrent BSS). An AP may reject the association request from a STA basedon the STA's HARQ capabilities.

The HARQ Capability IE and/or the HARQ Operation IE or a subset of thefields or subfields may be implemented as a field or a set of fieldsand/or a subfield or a set of subfields of an IE, e.g., an S1GCapability Element, an S1G Extended Capability, an VHT/HEW/VHSECapability Element, a VHT/HEWNHSE Extended Capability Element, or a partof a NDP, a control frame, a management frame, an extension frame, anMAC/PLCP headers fields, e.g., an SIG field, SIGA field, SIGB field,SIGC field, aframe control field, an HARQ Control field, etc.

HARQ ACK and/or NACK feedback may be provided. When the HARQtransmission is correctly received and decoded by a STA, the receivingSTA may ACK the HARQ transmission. When the HARQ transmission is notcorrectly received, the receiving STA may inform the transmitting STAthat it has not correctly received the HARQ packet, e.g., bytransmitting an NACK frame.

A control frame, a control extension frame, or an extension frame, a NDPframe, may be designated as the NACK frame. The NACK frame may beidentified by one or more of its Type field, Subtype field, or extensionfield, or NDP type field, or NDP MAC Frame Type field. FIG. 4illustrates an example of an NACK frame. The NACK frame may have one ormore of the following fields: a Frame Control field, a duration field,an RA field, an HARQ Info field, an FCS field, etc.

The Type field and/or the Subtype field may indicate that the frame isan NACK frame. The frame control field or another field in the frame, orPLCP header, or MAC header may include an extension field indicatingthat the frame is NACK frame. The extension field may be interpretedindependently or in combination with the Type and/or Subtype field. TheType of the NACK frame may be set as a NDP, Management, a Control, aData or an Extension type. For example, the NACK frame may be indicatedby the NDP MAC Frame Type field in the PLCP header.

The Duration field, for example, in the MAC or PLCP header, may be usedto reserve additional medium access time for a transmitting STA of theprevious HARQ packets to retransmit the HARQ packets, or transmit adifferent RV of the previous HARQ packets. If no medium access time isreserved for subsequent transmission or retransmissions, the Durationfield may be set to 0. No medium access time may be reserved whenmaximum number of retries is reached or the HARQ transmission sequenceis not contiguous.

The RA field may indicate the receiving STA's (the transmitter of theHARQ packet being NACKed) address, e.g., a MAC address, AID, PAID, etc.The HARQ Info field may include the information aboutthe HARQprocess/packets forwhich the NACK frame may be sent. The HARQ Info fieldmay provide information including, e.g., an HARQ Process ID subfield, anRV subfield, a Recommended RV and MCS subfield, a No HARQ Indicationsubfield, etc. The HARQ process ID subfield may be implemented usingHARQ Process ID, and/or packet Sequence Number and/or fragment Number.The RV subfield may indicate the RV for which the NACK may be sent. TheRV information may be omitted or set to empty or set to “0”, forexample, if the NACK is designated for an entire HARQ process. TheRecommended RV and MCS subfield may include recommendations for RVand/or MCS that may be used in the subsequent (re)transmissions. The NoHARQ Indication subfield may indicate that a STA may prefer not toreceive HARQ transmissions in the future.

One or more of the fields and subfields described above may beimplemented as an NDP frame. In the NDP frame, one or more fields and/orsubfields may be included in the PLCP header including, e.g., SIGA,SIGB, SIGC, or SIG field, etc.

Block ACK (BA) frame may be used to implement a NACK frame. FIG. 5illustrates an example of using a Block ACK frame as an NACK frameand/or multi-HARQ ACK/NACK frame. The Block ACK frame may be modified toact as a NACK frame and/or a multi-HARQ ACK/NACK frame. The MAC headermay include an extension field. The extension field, by itself, or incombination of the Type and Subtype frame may indicate that the currentframe is an NACK frame. The Type and Subtype fields may be used toindicate that the current frame is a BA frame.

The BA Control field of the BA frame may be modified in one or moreways. For example, one or more bits of the reserved (e.g., Bit 3 to Bit11) may be set to 1 to indicate that the current BA frame is an NACKframe. FIG. 6 illustrates BA Control Field setting to indicate an NACKframe. As illustrated in FIG. 6, the Multi-TID Subfield Value and theCompressed Bitmap Subfield Value may be set to 1 and 0 respectively toindicate that the current BA frame Variant is an NACK. The Multi-TIDSubfield Value and the Compressed Bitmap Subfield Value may be set to 1and 0 respectively to indicate that the current BA frame Variant is aMulti-HARQ ACK/NACK.

The Multi-TID subfield (e.g., set to 1), or any other subfield, incombination with one or more NACK indicator(s) may indicate that the BAmay include NACKs for multiple streams and/or HARQ processes. Thecombination may indicate that there may be multiple fields for multiplestreams and/or HARQ processes in the BA Information field and/or otherfields. For example, such indication may be used in a multiple Stop andWait (HARQ) process.

The Multi-TID subfield (e.g., set to 1), or any other subfield, incombination with one or more HARQ ACK indicator(s) may indicate that thecurrent frame may include ACKs for multiple streams and/or HARQprocesses. The combination may indicate that there may be multiple ACKfields for multiple streams and/or HARQ processes in the BA Informationfield. For example, such indication may be used in a multiple Stop andWait (HARQ) process.

The Multi-TID subfield (e.g., set to 1), or any other subfield, incombination with one or more HARQ indicator(s) may indicate that thecurrent frame may include ACKs/NACKs for multiple streams/HARQprocesses. The combination may indicate that there are multiple ACK/NACKfields for multiple streams/HARQ processes in the BA Information fieldor other fields. Each of such ACK/NACK subfields may have an ACK/NACKindication bit. When the ACK/NACK indication bit is set to 0, thesubfield may be an NACK field. When the ACK/NACK indication bit is setto 1, the subfield may be an ACK field. These indications may be used ina multiple Stop and Wait (MSOW) process. The ACK/NACK for multiple HARQprocesses may be referred to as Multi-HARQ ACK/NACK.

The TID_Info subfield of the BA Control field may include the HARQ ID orpart thereof, or the least significant 4 bits of the Sequence Number ofa packet, which may not have been correctly received and/or may be beingNACKed. One or more of the reserved bits (e.g., Bit 3 to Bit11) may beused to indicate that the HARQ ID or part thereof, or the leastsignificant bits of the Sequence Number of the packet, which may nothave been correctly received and/or may have been NACKed. The reservedbits may be used independently and/or in combination of the TID_Infofield. The TID_Info field may include and/or imply the number ofACKed/NACKed HARQ processes, for example, if ACK/NACK for multiple HARQprocesses are included in the Block ACK frame.

The BA Information field may be modified in one or more ways to providethe NACK related information. One or more of the following may apply.

The BA Information field may be omitted, e.g., when the NACK is sent(e.g., immediately) after the data packets and/or the reception of anNACK frame at the receiver's RA address implies that the prior dataframe was not correctly received. The BA Information field may includethe RV of the HARQ process for which an ACK/NACK may be sent. The BlockACK Starting Sequence Control may be set to the HARQ process ID, and/orthe Sequence Number of the packet that may not have been correctlyreceived and/or may have been NACKed.

The BA Starting Sequence Control may be set to the starting HARQ processID, and/or the Sequence Number of the starting packet that may not havebeen correctly received and/or is being NACKed. The BA Bitmap mayinclude bitmaps, which may indicate ACK/NACK for the HARQ processes,with the first bit may be used to indicate ACK/NACK for the startingHARQ process ID, and/or a starting packet. When a bit in the BA Bitmapis set to 0, the bit may indicate an NACK for the associated HARQprocess. When a bit in the Block ACK Bitmap is set to 1, that bit mayindicate an ACK for the associated HARQ process.

If the BA Information includes ACKs/NACKs for multiple HARQ processes,the Per-TID Info subfield may be set to the HARQ Process ID, or theSequence Number of the packet associated with the HARQ Process. An RVfield may be included for each of the HARQ ACK/NACKs. One or more bitsmay be used to indicate whether a HARQ process is being ACKed or NACKed.

The BA frames serving as NACK may include HARQ Info field and/orinformation from the HARQ Info field as described herein. The NACK orMulti-HARQ ACK/NACK may be implemented, for example, using NDP BlockACK. A (NDP) Block ACK Request (BAR) frame may be modified (e.g.,similarly as the BA frame) to be used as (NDP) Block ACK/NACK Request orRequest for Multi-HARQ ACK/NACK.

A combination of Type and Subtype field settings, for example, with Typeequal to 10 and Subtype equal to 1001, in the MAC header may imply thatthe frame (e.g., a QoS Data+CF-ACK frame) may serve as a QoS Data packetand a CF-ACK for the packet that the transmitting STA may have received.A combination packet Data+NACK frame may be defined. The Data+NACK framemay be implemented as an extension frame, for example, by setting theType equal to a value 11 and/or by setting the Subtype to one or more ofthe currently reserved values. A Data+NACK frame may reuse the Typeand/or Subtype field values that may be used for other type of frames,and an extension subfield in the MAC header or the PLCP header mayindicate that the frame is a DATA+NACK frame.

A frame, e.g., a data frame may have one or more bits of ACK/NACKindicator in the PLCP header and/or the MAC header of the frame. Forexample, if the ACK/NACK indicator is set to 0, the data packet mayserve as an NACK frame for the packet that may have been transmitted tothe transmitting STA immediately before the transmission of the currentframe. If the ACK/NACK indicator is set to 1, the data packet may serveas an ACK for the packet transmitted to transmitting STA immediatelybefore the transmission of the current frame.

Other types of combination frames may be implemented in a similarfashion, e.g., BlockAckReq+NACK, etc. The ACK/NACK implementationsdescribed herein may be used regardless the usage of HARQ. For example,the ACK/NACK implementations may be used to ACK/NACK other type oftransmissions. The NACK frames may include HARQ Info field orinformation from the HARQ Info field (e.g., as described herein) in afield (e.g., an existing or a new field), or in a MAC header and/or aPLCP header.

A STA (e.g., a receiving STA) may provide ACK and/or NACK feedback. Oneor more of the following may apply.

The STA may send an ACK to a transmitting STA, within SIFS time and/orlater to acknowledge that data bits associated with a HARQ transmissionor a HARQ process that may have been correctly received and/or decoded.The correct reception may be indicated, e.g., by passing of an MAC LayerFCS check and/or an LDPC check. The ACK may be transmitted, e.g., afterthe last HARQ transmission of the packet. The ACK may be transmitted ata scheduled time. The ACK may be part of a Data+ACK frame, Multi-HARQACK/NACK frame, or an A-MPDU or A-MSDU.

A receiving STA may transmit an NACK to a transmitting STA if the STAmay determine that a HARQ or a regular transmission was sent to itself,the received HARQ or the regular packet could not be decoded, or the FCScheck or the LDPC check of the transmission failed. Such an NACK mayfollow directly after the last HARQ transmission of the packet. The NACKmay be transmitted at a scheduled time. The NACK may also be part of aData+NACK frame and/or other type of combo packet including, e.g.,BlockAckReq+NACK. The NACK may be a part of a Multi-HARQ ACK/NACK frame,an A-MPDU, or A-MSDU.

A receiving STA may determine that a HARQ (or regular) transmission wasaddressed to itself when, for example, one or more HARQ or regularpackets may have been scheduled to be transmitted to a receiving STA byone or more scheduling IEs or frames, but the reception of such packetsfailed. The failure may be indicated by failed FCS/CRC/LDPC check of thePLCP header, the MAC header, and/or the MAC frame.

A receiving STA may determine that a HARQ (or regular) transmission wasaddressed to itself when a STA is scheduled to provide feedback on aHARQ or a regular packet that it may receive, but no packets werereceived in a relevant period of time.

A receiving STA may determine that a HARQ (or regular) transmission wasaddressed to itself when for example, a STA may detect a valid PLCPheader (e.g., when it may have passed the CRC test), but may fail todecode the packet correctly based on the PLCP header. The STA maydetermine that the PAID/AID/ID included in the PLCP header may matchwith its PAID/AID/ID, but may fail to decode the packet. The failure maybe indicated by, e.g., failed FCS test or LDPC test.

A receiving STA may determine that a HARQ (or regular) transmission wasaddressed to itself when for example, a STA may have detected a validPLCP header and a MAC header, where the MAC header may be consideredreliable and addressed to the receiving STA, but the STA may fail todecode the packet correctly. The failure may be indicated, e.g., byfailed FCS test or LDPC test. A MAC header may be considered reliable,for example, when the MAC header (or a Robust Portion thereof) is sentusing a more robust MCS; when the MAC header (or a Robust Portionthereof) has its own CRC and the CRC test past and the RA addressmatches the receiving STA's MAC address; and/or when PAID in the PLCPheader may match the receiving STA's PAID, and/or the RA address in theMAC header (or a Robust Portion thereof) may match the receiving STA'sMAC address.

To support HARQ operation, HARQ related parameters may be signaledduring the HARQ transmission. The HARQ related parameters may beincluded in the PLCP header and/or the MAC header. The PLCP header of anHARQ (or, e.g., regular HEWNHSE) packet may be characterized by one ormore of the following.

The PLCP header of an HARQ (or, e.g., regular HEWNHSE) packet mayinclude an indicator that the current packet is an HARQ packet. The PLCPheader may include a field indicating the HARQ process ID. A non-zeroHARQ Process ID field may imply that a packet is a HARQ packet.

The PAID and/or GrouplD field in the PLCP header may be used to includeadditional information on the extended PAID or AID, or other form of IDsof a receiving STA. The PLCP header may include the PAID or AID or otherform of IDs of the transmitting STA. The PLCP header may include a fieldindicating the RV of the current HARQ transmission. The value of RV0 orother RV number may indicate that the current HARQ packet is a firsttransmission of a packet. The RV field may be omitted, for example, if apre-determined order of transmitting RVs has been agreed upon. The PLCPheader may include a Retry field to indicate whether the current HARQpacket may be a first transmission or a retransmission, e.g., with adifferent RV number.

The MAC header of a HARQ (or HEW/VHSE) packet may be characterized byone or more of the following. The MAC header may be protected by sendingthe packet at a robust MCS and/or with its own CRC. The MAC header maybe considered valid, e.g., when the CRC or the LDPC check may pass. TheMAC header may be divided into two portions, a Robust MAC header and aRegular MAC header. The Regular MAC header may be encoded andtransmitted at the same MCS as the MAC frame body, while the Robust MACheader may be transmitted at a robust MCS and/or protected by its ownerror-detecting code, such as CRC. The fields in a Robust MAC headerthat may be transmitted at a robust MCS or protected by its own CRC mayinclude, e.g., RA/PAID/AID/or other type of receiver ID, SequenceNumber/HARQ Process ID, HARQ Indicator, RV, Retry, TA/PAID/AID or othertype of transmitter ID. The MAC header may include an indicator that thecurrent packet may be a HARQ packet. The MAC header may include a fieldindicating the HARQ process ID. A non-zero HARQ Process ID field mayimply that the current packet is a HARQ packet. The Sequence Number incombination of the TA field may be considered as the HARQ Process ID.The MAC header may include a field indicating the RV of the current HARQtransmission. The value of RV0 or any other RV number may indicate thatthe current HARQ packet is a first transmission of a packet. The Retryfield in the MAC header may be set to 0, e.g., to indicate that thecurrent HARQ packet may be a first transmission. The Retry field in theMAC header may be set to 1, e.g., to indicate that the current HARQpacket is a retransmission, e.g., with a different RV number.

The HARQ parameter signaling procedure may be characterized by one ormore of the following. A transmitting STA may indicate that the currentframe is a HARQ packet in the PLCP and/or the MAC header, or in theRobust and/or the Regular MAC header. If a HARQ packet is the firsttransmission of a new HARQ process, the transmitting STA may set theRetry field to 0 in the PLCP/MAC header, or in the Robust/Regular MACheader. Otherwise, the transmitting STA may set the Retry field to 1.The transmitting STA may set the RV field to a predetermined value toindicate that the current HARQ packet is the first frame of a new frame.The transmitting STA may set the RV field to a different pre-determinedvalue, or to the actual RV value of the HARQ packet in theretransmissions. The transmitting STA may include the HARQ process ID inthe PLCP/MAC header or in the Robust/Regular MAC header. Thetransmitting STA may use the Sequence Number of the packet as the HARQprocess ID, or set any part of the Sequence Number field, such as thefragmentation field, to/as the HARQ Process ID. The receiving STA mayprovide an ACK/NACK feedback for the HARQ frame addressed to it. TheACK/NACK feedback may include HARQ related parameters such as HARQProcess ID, RV number, Recommended RV/MCS, or No HARQ indication, etc.

HARQ operation using Speed Frame Exchange (SF) may be provided. FIG. 7illustrates an example design of an HARQ operation using the Speed FrameExchange. In a Speed Frame Exchange that may support HARQ operation, aData+ACK/NACK frame may be considered as a valid response frame in theSpeed Frame Exchange (HARQ operation) frame exchange sequence. An A-MSDUor an A-MPDU that may include an ACK, NACK, Block ACK/NACK, and/ormulti-HARQ ACK/NACK frame may be considered as a valid response frame inthe Speed Frame Exchange (HARQ operation) frame exchange sequence.

As illustrated in FIG. 7, STA1 may have a packet to send to STA2, andonce STA1 has obtained access to the channel, STA1 may initiate a HARQprocess, e.g., referred to as STA1 Data 1. The HARQ process may beidentified using the packet sequence number or other HARQ Process ID, bysending the first transmission TX1 of STA1 Data 1, e.g., identified by aspecific RV number, or a field with Retry equal to 0, or TX equal to 1.The value TXN may designate the Nth transmission of a HARQ process. Thetransmissions of a HARQ process may have same and/or different RVs,and/or may be transmitted using the same and/or different MCS′.

If the STA2 may determine that the transmission was addressed to itself,e.g., by decoding sufficient information from the PLCP header, MACheader, Robust MAC header, etc., the STA2 may reply using a combinationof first transmission TX1 addressed to STA1 of a HARQ process, e.g.,referred to as STA2 Data 1, which may be identified using a packetsequence number or an HARQ Process ID. For example, the transmission maybe identified by an RV number of a field with the value Retry equal to 0or Tx equal to 1, and/or an ACK/NACK for STA1 Data 1, TX1. Depending onwhether STA2 may successfully decode the TX1 of STA1 Data 1, the STA2may use ACK or NACK in a combination packet. If, for example, the FCS orLDPC check failed, the STA2 may include an NACK, otherwise the STA2 mayinclude an ACK. As illustrated in FIG. 7, the STA2 may include an NACKfor TX1 of the HARQ process STA1 Data 1 or for the HARQ process STA1Data 1. The combination packet, may be, e.g., a Data+ACK or a Data+NACKas described herein. The combination packet may be an A-MSDU or anA-MPDU. The A-MSDU or an A-MPDU may include an ACK/NACK, Block ACK/NACK,and/or Multi-HARQ ACK/NACK frame. These frames may be included as thefirst portion of the A-MPDU or the A-MSDU.

The STA1 may receive a combination packet from STA2 including, e.g., anNACK for STA1 Data 1, TX1, and TX1 of the HARQ process STA2 Data 1. TheSTA1 may reply with a combination of retransmission of STA1 Data 1,namely TX2, which may be the same as the TX1, or a different RV, and/ormay use a different MCS scheme, provided that the maximal number ofretry for the HARQ packet has not been reached, and an ACK/NACK for thefirst transmission TX1 of the HARQ process STA2 Data 1. As illustratedin FIG. 7, the STA1 may include an ACK for the first transmission TX1 ofthe HARQ process STA2 Data 1 or for the HARQ Process STA2 Data 1.

The STA2 may receive a combination packet from STA1 including, e.g., anACK for STA2 Data 1, TX1, and a retransmission of STA1 Data 1, TX2. TheSTA2 may reply with a combination of the first transmission of a newHARQ process, e.g., STA2 Data 2, TX1, e.g., if STA2 has a new packet totransmit to STA1, and an NACK for the retransmission TX2 of the HARQprocess STA1 Data 1, because the STA1 may have failed to correctlyreceive it. The failure of reception may be indicated by, e.g., failedFCS or failed LDPC check.

The STA1 may receive a combination packet from STA2 including, e.g., anNACK for STA1 Data 1, TX2 or for the HARQ process STA1 Data 1 and TX1 ofthe HARQ process STA2 Data 2. The STA1 may reply with a combination of asecond retransmission of STA1 Data 1, TX3, which may be the same as TX2or TX1, or a different RV, and an ACK for the first transmission TX1 ofthe HARQ process STA2 Data 2. The STA1 may use a different MCS scheme,provided that the maximum number of retries for the HARQ packet has notbeen reached.

The STA2, may receive a combination packet from STA1 including, e.g., anACK for STA2 Data 2, TX1 or STA2 Data 2, and a retransmission of STA1Data 1, TX3. The STA2 may reply with a combination of the firsttransmission of a new HARQ process STA2 Data 3, TX1, if STA2 has a newpacket to transmit to STA, and an ACK for the retransmission TX3 of theHARQ process STA1 Data 1 or for the HARQ process STA1 Data 1, if thepacket associated with the HARQ process STA1 Data 1 has been decodedcorrectly, after appropriate HARQ combining (e.g., CC or IR). Aftersending an ACK, the STA2 may flush the HARQ memory associated with thecorresponding HARQ process. The STA2 may maintain a record of the HARQprocess STA1 Data 1, which may have been correctly received for a periodof time so that if another packet arrives that is related to STA1 Data1, e.g., a Block ACK/NACK Request, Multi-HARQ ACK/NACK Request, or aretransmission of STA1 Data 1, STA2 may respond with an ACK for STA1Data 1 and discard the incoming packets. The STA2 may indicate in thetransmission that it has no more packets to transmit to STA1.

The STA1 may receive a combination packet from STA2 including, e.g., anACK for STA1 Data 1, TX3 or for the HARQ process STA1 Data 1, and TX1 ofthe HARQ process STA2 Data 3. The STA1 may reply with an ACK if it maybe able to correctly decode the packet that is associated with the HARQprocess STA2 Data 3. The STA1 may erase stored copies related to STA1Data 1. After sending an ACK, the STA2 may flush the HARQ memoryassociated with the corresponding HARQ process. STA2, after receivingthe ACK from STA1, may erase stored copies related to STA2 Data 3.

The ACK and NACK may be implemented using ACK, Block ACK frames, or NACKframe, combo packets such as Data+ACK, Data+NACK, multi-HARQ ACK/NACK,or an A-MSDU or an A-MPDU including one or more of the previous types offrames. The time between the frame exchanges may be an Inter FrameSpace, e.g., SIFS, PIFS, etc., or an IFS of one or more time units.

The HARQ operation may be supported using the multi-frame TXOP. FIG. 8illustrates an example HARQ operation using the multi-frame TXOP. AnHARQ MAC implementation using multi-frame TXOP may be provided. Asillustrated in FIG. 8, STA1 may have a packet to send to STA2, and onceSTA1 has obtained an TXOP to access the channel (e.g., by RTS/CTS frameexchange with STA2 or a scheduled or polled TXOP or EDCA TXOP), the STA1may initiate a HARQ process, e.g., referred to as STA1 Data 1, which maybe identified using a packet sequence number or other HARQ Process ID,or by sending the first transmission TX1 of STA1 Data 1, e.g.,identified by a specific RV number or a field with value Retry equal to0 and/or Tx equal to 1.

If STA2 can determine that the transmission was addressed to itself,e.g., by decoding information from the PLCP header, MAC header, RobustMAC header, etc., it may reply with an ACK/NACK for STA1 Data 1, TX 1 orthe HARQ process STA1 Data 1. The STA2 may reply with an ACK or NACKbased on whether the STA2 could successfully decode TX1 of STA1 Data 1.If, for example, the FCS or LDPC check failed, the STA2 may reply withan NACK; otherwise, the STA2 may reply with an ACK. As illustrated inFIG. 8, STA2 may include an NACK for the HARQ process STA1 Data 1.

STA1 may receive an NACK for STA1 Data 1, TX1 from STA2. The STA1 mayreply with a retransmission of STA1 Data 1, TX2, which may be the sameas the TX1, or a different RV, and/or may use a different MCS scheme,provided that the maximal number of retry for the HARQ packet has notbeen reached.

The STA2 may receive a retransmission of STA1 Data 1, namely TX2 fromSTA1. The STA1 may decode the received packet using appropriate HARQcombining (e.g., CC or IR). The STA2 may reply with an NACK for theretransmission TX2 of the HARQ process STA1 Data 1 or the HARQ processSTA1 Data 1, because the STA2 may have failed to correctly decode thedata associated with the HARQ process. The failure to decode the datamay be indicated by, e.g. by a failed FCS.

The STA1 may receive a NACK for STA1 Data 1, TX1 or for STA1 Data 1. TheSTA1 may reply with a second retransmission of STA1 Data 1, TX3, whichmay be the same as TX2 or TX1, or a different RV, and/or use a differentMCS scheme, provided that the maximal number of retry for the HARQpacket has not been reached.

The STA2 may receive the retransmission of STA1 Data 1, TX3, and maydecode the received packet using appropriate HARQ combining (e.g., CC orIR), and may reply with an ACK for the retransmission TX3 of the HARQprocess STA1 Data 1 or for the HARQ process STA1 Data 1, if the packetassociated with the HARQ process STA1 Data 1 has been decoded correctly.After sending an ACK, the STA2 may flush the HARQ memory associated withthe corresponding HARQ process. The STA2 may maintain a record of theHARQ process STA1 Data 1, which may have been correctly received for aperiod of time so that if another packet arrives that is related to STA1Data 1, e.g., a Block ACK/NACK Request, Multi-HARQ ACK/NACK Request, ora retransmission of STA1 Data 1, STA2 may respond with an ACK for STA1Data 1 and discard the incoming packets. The STA1 may receive the ACKfor STA1 Data 1, TX 3, or for the HARQ process STA1 Data1 and may erasestored copies related to STA1 Data 1 in its data buffer or memory.

The ACK and NACK may be implemented using existing ACK, Block ACKframes, or other (e.g., newly designed) NACK frames, multi-HARQACK/NACK, or any A-MSDU or A-MPDU including any of the previous types offrames. The time between the frame exchanges may be an Inter FrameSpace, such as SIFS, PIFS, HARQ IFS (HIFS), etc., or an IFS of one ormore time units.

The HARQ operation may be supported by using scheduled HARQ operation,e.g., using PSMP (Power Saving Multi-Poll) slots, S-ASPD (ScheduledAdvanced Power Saving Delivery) slots, RAW (Restricted Access Window)slots, PRAW (periodic Restricted Access Window) slots, TWT (Target WakeTime) or any other slots defined. These and potentially new slots orperiods may be referred to as HARQ Slots (HSlots).

FIG. 9 illustrates an example of a scheduled HARQ. As illustrated inFIG. 9, an AP may allocate one or more up link (UL), down link (DL) orcombined UL/DL Hslots for a STA. The scheduled HSlots may be periodic oraperiodic. An AP may include a schedule in a beacon frame or a ResourceAllocation frame, or a NDP, Management, Control, Data, and/or Extensionframe.

A slot may be assigned to one STA or a group of STAs. A slot assignedfor a group may be contention-based or contention-free. In acontention-free slot for a group of STAs, the order of transmissions orreceptions may be pre-determined or signaled (e.g., inherently signaled)through a beacon frame, a scheduled frame, or a NDP, management, controland/or extension frame.

An UL slot may be used by a STA to transmit a UL frame, a HARQ frame, acombination frame such as a Data+ACK/NACK frame, an A-MPDU and/or anA-MSDU frame, which may include the data frames and other management,control and/or extension frames, e.g., ACK/NACK, multi-HARQ ACK/NACKframes. An UL slot may be long enough for the transmitting STA tocomplete its transmission and for the receiving STAs to transmit anACK/NACK frame. An UL slot may be provided for a STA to transmitACK/NACK frames, multi-HARQ ACK/NACK feedback for previous receivedframes, ACK/NACK Request, Block ACK/NACK Request or Multi-ACK/NACKRequest frames. An UL slot may be used for peer-to-peer transmissionsamong the STAs.

A DL slot may be used by the AP to transmit a DL frame, a HARQ frame, acombination frame, e.g., a Data+ACK/NACK frame, an A-MPDU and/or anA-MSDU frame, which may include data frames and other management,control and/or extension frames such as ACK/NACK, multi-HARQ ACK/NACKframes or scheduling frames. If a DL frame is assigned to a group ofSTAs, the AP may use the DL slot to transmit group-addressed multicastor broadcast frames. The AP may transmit multi-user A-MSDU and/or A-MPDUto one or more STAs. An AP may utilize an DL frame to transmit ACK/NACK,multi-HARQ ACK/NACK feedback for previous frames transmitted to it, orACK/NACK Request, Block ACK/NACK Request or Multi-ACK/NACK Requestframe. A combined UL/DL slot may be used as multi-frame TXOP or a SpeedFrame Exchange session for HARQ. A combined UL/DL slot may be used by aSTA to transmit one or more HARQ frames to different STAs.

An AP may assign a list of DL slots and one or more UL to a STA. Duringthe DL slots the AP may transmit one or more HARQ processes packets tothe STA. In the UL slot, the STA may provide ACK/NACK and/or multi-HARQACK/NACK feedback to the AP, e.g., when the STA may be polled by the APor after the STA may receive an ACK/NACK Request, Block ACK/NACKRequest, or Multi-ACK/NACK Request frame. The AP may assign a list of ULslots and one or more DL slots to a STA. During the UL slots the STA maytransmit multiple HARQ processes packets to a STA or the AP, and in theDL slot, the AP may provide ACK/NACK or multi-HARQ ACK/NACK feedback tothe STA, e.g., when the AP receives an ACK/NACK Request, Block ACK/NACKRequest, or Multi-ACK/NACK Request frame.

WiFi multiple stop and wait (MSOW) HARQ operations may be provided. TheMSOW HARQ operations may provide higher throughput and efficiency due tosmaller feedback overhead. FIG. 10 illustrates an example of scheduledMSOW HARQ operations. One or more UL slots may be assigned to a STA. TheSTA may start one or more HARQ processes.

As illustrated in FIG. 10, a STA may transmit one or more packetsassociated with the multiple HARQ processes to an AP (or to another peerSTA) in each of the UL slots assigned to it, e.g., without firstreceiving the feedback. The maximum number of HARQ processes (e.g.,incomplete HARQ processes) per STA may be subject to a limit, e.g., asindicated by Maximal Concurrent HARQ Process parameters specified in theHARQ Capability and/or Operation Element. In a DL slot assigned to theSTA, the AP (or a peer STA) may provide ACK/NACK, multi-HARQ ACK/NACKfeedback to the UL HARQ packets associated with the multiple stop andwait HARQ processes. The ACK/NACK, multi-HARQ ACK/NACK feedback may bepart of a A-MSDU or A-MPDU in a DL slot, or DL/UL slot, for example afeedback slot, assigned to the STA. The ACK/NACK, multi-HARQ ACK/NACKfeedback may be part of a A-MSDU or A-MPDU in a DL slot, or DL/UL slot,for example a group feedback slot, assigned to a group of STAs. TheA-MSDU or A-MPDU may provide ACK/NACK for multiple STAs for one or moreHARQ processes. The AP may provide ACK/NACK or multi-HARQ ACK/NACKfeedback to the STA, e.g., after receiving an ACK/NACK Request, BlockACK/NACK Request or Multi-ACK/NACK Request frame.

An AP may transmit one or more packets associated with multiple HARQprocesses to a STA in each of the DL slots assigned to the STA or agroup of STAs, without first receiving the feedback. The maximum numberof HARQ processes (e.g., incomplete HARQ processes) per STA may besubject to a limit, e.g., as indicated by the Maximal Concurrent HARQProcess parameters in the HARQ capability and/or operation informationelement. In an UL slot assigned to a STA, the STA (or a peer STA) mayprovide ACK/NACK, multi-HARQ ACK/NACK feedback to the UL HARQ packetsassociated with the multiple stop and wait HARQ processes. The ACK/NACK,multi-HARQ ACK/NACK feedback may be part of a A-MSDU or A-MPDU in a ULslot, or DL/UL slot, for example a feedback slot assigned to the STA.The ACK/NACK, multi-HARQ ACK/NACK feedback may be provided in a UL slot,or DL/UL slot, for example a group feedback slot, assigned to a group ofSTAs, where a group of STAs may provide ACK/NACK for multiple HARQprocesses. The STA may provide ACK/NACK or multi-HARQ ACK/NACK feedbackto the AP, e.g., when the STA may be polled by the AP or the STA mayreceive an ACK/NACK Request, Block ACK/NACK Request or Multi-ACK/NACKRequest frame.

The MSOW HARQ operations may be conducted by transmitting HARQ packets,A-MSDU or A-MPDU packets, e.g., including HARQ packets, ACK/NACK,multi-HARQ ACK/NACK in combined DL/UL slots or other type of Hslots. Thetransmitting STA may request ACK/NACK feedback using a HARQ Feedbackrequest frame. Upon the reception of which, the receiving STA or an APmay transmit Data+ACK/NACK, ACK, NACK or Multi-HARQ ACK/NACK frame as aresponse.

FIG. 11 illustrates an example of a MSOW HARQ process using aggregatedpackets. As illustrated in FIG. 11, STA1 may transmit an aggregatedpacket, e.g., an A-MDPU or an A-MSDU (e.g., a constructed A-MDPU orA-MSDU) to STA2. For example, the STA1 may transmit the aggregatedpackets with HARQ packets associated with multiple HARQ processes, e.g.,the first transmissions TX1 of the HARQ processes, HARQ P1, HARQ P2, . .. , HARQ PN. The HARQ packets associated with multiple HARQ processesmay be separated by delimiters, CRC fields, padding, etc. The totalnumber of HARQ processes (e.g., incomplete HARQ processes) may besubject to maximal Concurrent HARQ Process parameter, e.g., indicated inan HARQ Capability or Operation information element. The last packetincluded in the aggregated packet may also be a HARQ Feedback requestframe, or a Multi-HARQ Feedback request frame requesting feedback forthe multiple HARQ processes. A HARQ Feedback request frame, or aMulti-HARQ Feedback request frame requesting feedback for the multipleHARQ processes may follow immediately or after some time after thecompletion of the aggregated packets with HARQ packets associated withmultiple HARQ processes.

The STA2 may respond, e.g., after some IFS (e.g., SIFS time) or at alater point of time, with a Multi-HARQ ACK/NACK frame, in which STA2 mayACK for HARQ processes for which the data may be correctly received, andNACK for HARQ processes for which the data may not be correctlyreceived. The failure to receive data correctly may be indicated byfailed FCS or LDPC checks, e.g., after being polled by the AP or afterreceiving an ACK/NACK Request, Block ACK/NACK Request, or Multi-HARQACK/NACK. The Multi-HARQ ACK/NACK frame may be part of an A-MPDU orA-MSDU, which may include data frames for STA1.

STA1 may receive the Multi-HARQ ACK/NACK frame. The STA1, e.g., afterreceiving the Multi-HARQ ACK/NACK frame, may erase the copies of dataassociated with those HARQ processes for which an ACK may have beenreceived from STA2. The STA2 may send single HARQ packet or aggregatedpackets that may include retransmissions TX2 for HARQ processes forwhich NACK may have been received from STA2. If no ACK or NACK has beenreceived for one or more HARQ processes, the latest version of theseHARQ processes that has not been ACKed or NACKed may be included in theaggregated packets. If the total number of HARQ processes (e.g.,incomplete HARQ processes) per STA is less than the maximal ConcurrentHARQ Process, the STA1 may initiate new HARQ processes and may includethe first transmission, TX1, of these new HARQ processes in the sameaggregated packet. The aggregated packet may include ACK/NACK for a HARQprocess, e.g., sent by STA2 to STA1. STA1 may continue transmittingretransmissions for HARQ processes for which the data may not have beenACKed. The STA1 may transmit retransmissions for HARQ processes untilthe maximal retry number for HARQ has been reached. The transmitting STAmay request (e.g., explicitly request) ACK/NACK feedback using an HARQFeedback request frame. The receiving STA on receiving the request maytransmit Data+ACK/NACK, ACK, NACK or Multi-HARQ ACK/NACK in response.

HARQ Operation fault recovery may be provided. If a transmitting STAtransmits a packet of data, which may be a RV, that is associated with aHARQ process, the STA may erase the copies associated with the HARQprocess if the HARQ process has been ACKed by the receiving STA. Thetransmitting STA may transmit the same version of the packet associatedwith the HARQ process, e.g., with a different MCS, if an NACK has beenreceived for the HARQ process from the receiving STA and the HARQoperation is set to, e.g., Chase Combining. The transmitting STA maytransmit a different RV of the packet associated with the HARQ process.The different RV may be determined beforehand and the packet may besent, e.g., with a different MCS, if an NACK was received for the HARQprocess from the receiving STA and the HARQ operation is set to, e.g.,Incremental Redundancy.

The transmitting STA may maintain a HARQ_Timeout counter for the HARQprocess. The transmitting STA may retransmit the last version of thepacket associated with the HARQ process to the receiving STA, e.g.,using a lower MCS, if no ACK or NACK has been received from thereceiving STA when the HARQ_Timeout counter expires, or when a scheduledACK/NACK feedback was not received.

If a receiving STA receives a frame and may not correctly decode thePLCP header, it may discard the frame. If the STA correctly decodes thePLCP header, e.g., indicated by CRC and/or LDPC checks, and the packetis a HARQ frame, the STA may respond with an ACK frame to thetransmitting STA, erase each of the stored copies associated with theHARQ process if it correctly decodes the data associated with the HARQprocess, e.g., as may be indicated by CRC/FCS/LDPC checks. The decodingof data may involve combining the received HARQ packet with previouslyreceived HARQ packets and versions of the same HARQ process ID. Thereceiving STA may maintain a record of the HARQ process that may becorrectly received for a period of time. The receiving STA may maintainthe record so that if one or more packets (e.g., such as a BlockACK/NACK Request, Multi-HARQ ACK/NACK Request, or a retransmission ofthis HARQ process) related to the HARQ process arrive, the receiving STAmay respond with an ACK for the HARQ process and discard the incomingpacket(s).

The receiving STA may store the received frame (or the soft bits ofreceived data packet), and send to the transmitting STA an NACK for theHARQ process, if the receiving STA could determine that the HARQ packetis destined to itself, e.g., by evaluating the PLCP header, MAC header,or Robust MAC header as described herein, the HARQ process ID, and thedata associated with the HARQ process cannot be correctly decoded, e.g.,as indicated by failed CRC/FCS/LDPC checks. The decoding of data mayinvolve combining the received HARQ packet with previously received HARQpackets and versions of the same HARQ process ID. The receiving STA maydiscard the frame, if the receiving STA could not determine that theHARQ packet is destined to itself.

The ACK/NACK/Data frames may be transmitted as a part of a single frame,or a combo frame such as Data+ACK/NACK or as a part of an aggregatedframe such as A-MPDU or A-MSDU.

The HARQ may be utilized by WiFi devices for higher throughput andefficiency. HARQ packets may be transmitted at higher MCS than normalpackets. If a STA starts to receive a packet and has correctly decodethe PLCP header, e.g., as may be indicated by CRC and/or LDPC checks,and the packet is a HARQ frame, the receiving STA may respond with anACK frame to the transmitting STA.

If the data associated with the HARQ process cannot be correctlydecoded, e.g., as may be indicated by failed CRC/FCS/LDPC checks, thereceiving STA may not wait for an EIFS time before transmitting. Thereceiving STA may send (e.g., immediately send), to the transmittingSTA, an NACK for the HARQ process; for example, the receiving STA maysend the NACK after an SIFS time, e.g., if the receiving STA determinesthat the HARQ packet is destined to itself, (e.g., by evaluating thePLCP header, MAC header, or Robust MAC header as described herein). Sucha decoding process may be combined with previously received HARQ packetsand versions of the same HARQ process ID.

Cross layer implementations for HARQ in WiFi may be provided. TheTXVector and the RXVector may be modified to support HARQ operation inWiFi. For example one or more parameters may be provided including,e.g., HARQ Transmission, HARQ Type, RV, HARQ Process ID, an New HARQIndication (or Retry indicator), and/or LDPC Check Failed. The HARQTransmission parameter may provide an indicator that thetransmission/reception may be using HARQ. The HARQ Type parameter mayindicate whether the HARQ may be Chase Combining or IncrementalRedundancy. The RV parameter may indicate the redundancy version thatmay be used in the current transmission or reception. The HARQ ProcessID parameter may indicate the ID of the HARQ process. The New HARQIndication (or Retry indicator) may indicate whether the current HARQtransmission/reception is a new HARQ process. The LDPC Check Failedparameter may be in RXVector and may indicate that the LDPC check hasfailed for the currently received packet or HARQ Process.

PHY-SAP primitives, e.g., PHY-TXSTART.request, PHY-RXSTART.indicationmay be changed to support HARQ. The PHY-TXSTART.request may include theTXVector that may include the HARQ related parameters as describedherein. The PHY-TXSTART.request primitive may be issued by the MACsublayer to the PHY entity when the MAC sublayer may begin thetransmission of a PSDU. If the PSDU is a HARQ PSDU, HARQ relatedinformation may be included in the TXVECTOR. If the HARQ transmission isindicated in the TXVECTOR, the PHY layer may start the HARQ transmitstate machine. The PHY-RXSTART.indication may include the RXVECTOR thatmay include the HARQ related parameters as described herein when acorrectly decoded PLCP header has an HARQ indication and/or includes oneor more HARQ related parameters.

HARQ may provide transmission error control in wireless communicationnetworks, which may rely on a combination of error correction codesand/or retransmissions. HARQ may be used for transmission error controlin wireless standards, e.g., High Efficiency WLAN (HEW), Wireless NextGeneration (WNG), etc. HARQ may provide increased per-link robustnessand/or per-link throughput for WiFi systems. To provide efficient androbust HARQ operation in WiFi systems, one or more aspects related toHARQ operation may be designed.

HARQ operations in WiFi networks may be provided. In WiFi networks, atransmission failure may occur, e.g., due to a collision, poor channelcondition, or other interferences. WiFi networks may not be able todistinguish between the failures that may occur. WiFi specifications maynot provide mechanisms (e.g., efficient mechanisms) to distinguishbetween these types of failures.

In Wi Fi network, the information available in a MAC header, forexample, the transmitter MAC address, the receiver MAC address etc. maybe used for HARQ operations. Stations (STAs) may decode MAC headersuccessfully to determine attributes, e.g., MAC address of thetransmitting and the receiving devices (e.g., STAs). To support HARQoperation in a WiFi network, the information included in the MAC headermay be decoded, even when the data in a MAC frame is not decodable. Insome cases, a MAC header may be coded in combination with the rest ofdata with no additional protection, which may make the effectiveretrieval of the MAC header difficult. WiFi networks may be optimized(e.g., the latency may be minimized), e.g., to retrieve informationincluded in a MAC header.

In WLAN systems, HARQ retransmission implementations and rules, formatof a HARQ retransmission packet may not be defined. How to specify theprotocol, or schedule for HARQ retransmissions is an open problem forthe WiFi system which operates on a CSMA/CA basis. Also the physicallayer processing for retransmission in a WiFi network is not optimizedfor HARQ based retransmission. In order to have betterperformance/decoding latency, it is desirable to optimize the physicallayer processing for retransmissions for HARQ based retransmission.Optimizations may include methods to increase frequency/spatialdiversity, reduce latency, or minimize signaling overhead.

A frame aggregation scheme may be provided. For example, one or more MACservice data units (MSDUs) may be aggregated to form an aggregated MSDU(A-MSDU). One or more MAC protocol data units (MPDUs) may be aggregatedtogether to form an aggregated MPDU (A-MPDU). One or more physical layerservice data units (PSDUs) may be aggregated together to form anaggregated PSDU (A-PSDU). When multiple PSDUs are aggregated together,e.g., if a single PHY header is mistakenly received, then each of thefollowing PSDUs in the same A-PSDU may not be properly received. HARQschemes in case of frame aggregation may be provided. LDPC codes in WLANsystems may be provided that may work with chase combining (CC) basedHARQ operations, incremental redundancy (IR) based HARQ operations,and/or with HARQ with frame aggregation.

In HARQ combining, errors based on collisions may be distinguished fromerrors based on noise and/or interference. Combining information frompackets that may have errors based on collisions may result in worseperformance than the ones where no HARQ is used. A mid-segment may beused, which may enable the receiver to identify whether an error isbased on collision or not. The mid-segment may be a repeat of a PLCPheader (e.g., an existing PLCP header) with the same and/or differentMCS as the original header. The mid-segment may be a repeat of the PLCPheader with the L-STF, L-LTF and an HARQ SIG frame (e.g., a new HARQ SIGframe) including information such as the length to the next mid-segment,the retransmission number, and/or the code redundancy version, acombination of the L-STF and L-LTF, and/or a blank period of notransmission.

A receiver may use the mid-amble to estimate a collision metric. Thecollision metric may be used, for example, when the transmission fails.The receiver may be able to identify if the failure is due to acollision or a noise and/or interference. The receiver may feed thisinformation back to the transmitter. The transmitter may use theinformation to improve the CSMA/CA multiple access parameters.

Collision metrics may provide information including, for example, changein interference/noise estimates, inability to decode PLCP information inthe SIG, LLR statistics in the decoder, etc. Using the change ininterference/noise estimates, if the interference or noise estimatechanges drastically between mid-segments, the receiver may imply thatthere was a collision. Using the inability to decode PLCP information inthe SIG, if the SIG decoding fails, the receiver may decide that therehas been a collision. Using the LLR statistics in the decoder, if theLLR statistics undergoes an abrupt change, the receiver may decide thatthere was a collision.

A receiver may send an ACK (e.g., a partial ACK) to a transmitter toindicate the failure of a mid-segment. When a STA joins a network it mayindicate support for mid-segment collision detection capabilities, whichthe STA may exchange with a BSS. An AP may send the mid-segmentparameters to the STA. The mid-segment parameters may include the numberof mid-segments (e.g., if the number of mid-segments is more than one).The mid-segment parameters may further include a mid-segmenttiming/interval. This interval may be a fixed value, estimated (e.g.,implicitly estimated) based on the number of mid-segments and the lengthof the packet, and/or a value that may be signaled to the receiver atthe start of a packet through a HARQ SIG.

A transmitter may acquire a channel (e.g., based on contention ordeterministically) and may send information to a receiver. The receivermay decode the information. If the information is decoded correctly, thesession may end. If the information is decoded incorrectly, the receivermay estimate the collision metric based on the mid-segment method(s)available. The receiver may use multiple collision metric estimators tominimize the probability of false alarm. The receiver discards theinformation, for example, when a collision may occur. The receiver maycombine the information with subsequent HARQ transmissions, for example,when a noise and/or interference based failure may occur. The receivermay feedback the collision status to the transmitter, e.g., tofacilitate a HARQ retransmission, and/or assist in fine-tuning thecollision avoidance mechanism of the transmitter and/or the network.Frame aggregation, e.g., as described herein, may be used to identifycollisions by the FCS in each PSDU.

A MAC header design that may be robust and/or decodable independent ofthe data may be provided. Such a design may allow intended receivers ofretransmitted packet to reliably combine one or more transmissions ofthe same data packet. A MAC header may have a maximum of 36 bytes. In aMAC data frame, the MAC header may followed by data bytes and a framecheck sequence (FCS) of 4 bytes that may be used to determine if the MACheader and data bytes are received correctly. An additional CRC of 1-4bytes may be added to the end of the MAC header. FIG. 12 illustratessuch a MAC header with a CRC field (e.g., 1 to 4 bytes long) appendedthe end of the MAC frame. The presence of the CRC field may be signaledby using combinations of reserved bits in the frame control field foreach of the one or more (e.g., four) possible frame types. The CRC maybe derived by puncturing (e.g., appropriately puncturing) a CRC (e.g., acurrent CRC) or by using a different generator polynomial. Instead of aCRC, a byte-error correcting code (e.g., a Reed-Solomon code) may beused by shortening a code (e.g., an existing code). Such a code mayenable error correction and/or detection.

In some systems, a MAC header may be transmitted using the same MCS asthe data. A separate MCS for a MAC header may be provided. A MAC headermay have the same code rate but may have a lower modulation mode thanthe data. The lower modulation mode than data may provide addedrobustness to the MAC header. The information of the differentmodulation mode may be indicated as an offset from the data modulation,e.g. one mode below the data. For example, if data is sent with 64 QAM,the MAC header may be sent with 16 QAM, using the same code rate. TheMAC header may be zero-padded to make up an integral number of OFDMsymbols, e.g., depending on the bandwidth mode. The MAC header may haveboth different code rate and modulation mode as compared to the data.This information about different code rate and modulation may beindicated as offset from the data MCS, e.g. the MAC header MCS may bespecified to be one below that of the data. The MAC header may bezero-padded to make up an integral number of OFDM symbols, depending onthe bandwidth mode.

Termination of MAC header convolution code may be provided. A MAC headermay be terminated by one or more (e.g., six) additional zero-bits sothat the trellis may be terminated at the end of the MAC header. Thismay allow the MAC header to be decoded as a block code and may provideadditional robustness to the decoding.

LDPC coding for MAC header may be provided. For example, LDPC code ofrate % with information bit length of 324 as the smallest codeword maybe used. The MAC header, e.g., at 36 bytes, may have 288 bits. With anadded CRC and/or zero-padding, the MAC header may be coded with rate %LDPC. This may allow the MAC header to be decoded independent of thedata, and, may provide extra robustness.

A SIG field with MAC header information may be provided. The SIG filedmay be located in the PHY layer. Since the SIG field may be transmittedwith the lowest MCS, some information in the MAC header may be extractedto form an additional SIG field; examples of information that may beextracted include: TX addresses, RX addresses, sequence control fields,etc. This SIG field may be coded with rate % convolution code or LDPCcodes as described herein.

HARQ retransmission procedures may be provided. A WiFi system mayoperate on an un-licensed band, and, interference from WiFi systems ornon-WiFi systems may corrupt the WiFi transmissions, e.g., due to badchannel condition, collision with interference signals, etc. When therehas been a HARQ transmission collision, the receiver may ignore thecorrupted transmission and may not try to combine it with other receivedpacket. It may be the receiver that makes the decision whether to applyHARQ combining. Each HARQ transmission may need to be self-decodable.Self-decodable HARQ implementations for WiFi systems may be provided,e.g., for Type I, II, and III as disclosed herein.

In a type I HARQ, HARQ transmission and retransmission(s) may have thesame MCS level, e.g., they may use the same coding rate and/ormodulation scheme. In this case, chase combining may be utilized atreceiver side. In a type II HARQ, HARQ transmission andretransmission(s) may have the same coding scheme with the same codingrate, but may have different modulation schemes. At receiver side, a LLRcombine may be applied on the receiver side. For example, the LLRcombine may be applied after de-mapper and de-interleaver.

In a type Ill HARQ, HARQ transmission and retransmission(s) may have thesame low data rate mother code, but may have different puncture schemes.At receiver side, a HARQ combining may be implemented by rebuild the setreceived coded bits. The rebuild coded bits may come from both HARQtransmission and retransmissions and the size of rebuild coded bits maybe larger than each individual HARQ transmission or retransmission.

One or more types of HARQ schemes may be signaled in SIG field such thatthe receiver may choose the way to decode the packet with or withoutHARQ combining. HARQ transmission or retransmission may be signaled(e.g., explicitly signaled) in a SIG field.

In WiFi systems, one or more transmission and retransmission schemes maybe allowed, e.g., one or more of the following. HARQ transmissions withone or more spatial streams (e.g., different spatial streams) may beallowed. For example, the first transmission may be with two datastream, while the HARQ retransmission may be with one data stream. Thefirst transmission may be with STBC, while the HARQ retransmission maybe without STBC. HARQ transmission with different bandwidths may beallowed. For example, the first transmission may be with 20 MHz, whilethe HARQ retransmission may be with 40 MHz.

Hybrid ARQ system may combine a received packet with the previoustransmissions, such that time diversity may be achieved. By modifyingthe transmitter for HARQ retransmission, or providing one or moreschemes for one or more HARQ transmissions, time diversity, spatialdiversity, and/or frequency diversity may be provided.

Cyclic shift diversity (CSD) Design for HARQ Retransmission may beprovided. CSD may be introduced in WiFi system for multiple antennatransmissions. The cyclic shift may be fixed. For example, Table 1illustrates cyclic shift values of HT portion of packet.

TABLE 1 T_(CS) ^(iSTS) values for HT portion of packets Number CyclicCyclic Cyclic Cyclic of shift for shift for shift for shift forspace-time space-time space-time space-time space-time streams stream 1(ns) stream 2 (ns) stream 3 (ns) stream 4 (ns) 1 0 — — — 2 0 — — — 3 0−400 −200 — 4 0 −400 −200 −600

With HARQ retransmission, the cyclic shift values for each space-timestream or transmit chain may be redesigned. For example, the order ofthe cyclic shift values for each stream may be changed or the values maybe changed directly. In order to perform this, the first HARQtransmission, second transmission and so on may be signaled in the SIGfield. The cyclic shift values for HARQ retransmission(s) may bepre-defined and/or broadcasted, e.g., in a Beacon frame. This processingmay be transparent to receiver, and, the receiver may apply HARQcombining normally.

STBC Design for HARQ retransmission may be provided. STBC may beutilized in WiFi systems. For example, STBC may be used after theconstellation mapper and before the CSD. One STBC mapping may be usedfor the first transmission and odd number of HARQ retransmission(s), andanother STBC mapping may be used for the even number of HARQretransmission(s). For example, the STBC mapping for the odd number ofHARQ (re)transmission(s) may utilized the mapping provided in FIG. 13,while the STBC mapping for the even number of HARQ retransmission(s) maybe redefined. FIG. 13 illustrates an example of STBC mapping for HARQtransmissions for two spatial time streams and 1 data stream case. OtherSTBC mapping may be possible. The receiver may be provided with the STBCmapping for a HARQ (re)transmission. The STBC mapping may be pre-defined(e.g., explicitly in a standard).

Spatial mapping for HARQ retransmission may be provided. Spatial mappingmay be defined in WiFi system, e.g., after CSD block and before IDFT. Aspatial mapping and/or steering matrix Q may be applied on the multiplespatial time streams out of CSD processing block, e.g., to convert theminto multiple transmission chains. The Q matrix may be defined persub-carrier, per multiple sub-carriers or per frequency channel. Thesize of Q matrix may be N_TX×N_STS.

Q matrix may vary from one transmission to other. It may not benecessary that the Q matrix on a certain sub-carrier remain the same forHARQ retransmission. A WiFi device may use the same method to calculatethe Q matrix for HARQ retransmission and another Q matrix (e.g., new Qmatrix) may be highly correlated with the Q matrix for HARQtransmission, e.g., if channel variation from the original transmissionto retransmission is small. With HARQ transmission the Q matrix for theHARQ retransmission may be modified, e.g., such that the spatialdiversity may be better achieved. For example, a simple columnpermutation of Q matrix may be applied for HARQ retransmission(s). Thisprocessing may be transparent to receiver, and the receiver may applyHARQ combining normally.

Timestamp design for HARQ retransmission may be provided. Timestamp ofthe previous HARQ transmission may be indicated in the HARQretransmission, such that the receiver may know whether it may combinethe current received frame with previously received and/or saved frame.The timestamp may be indicated in a SIG field of HARQ retransmissionframe and/or a MAC header of HARQ retransmission frame. A Timestampfield (e.g., as defined in 802.11-2012 standard) may be used. TheTimestamp field may represent the value of the timing synchronizationfunction (TSF) of a frame source. The length of the Timestamp field maybe eight octets.

PSDU frame aggregation with HARQ may be provided. FIG. 14 illustrates anexample of PSDU aggregation supporting HARQ. Aggregation may be of twotypes: MSDU aggregation and MPDU aggregation. In MSDU aggregation, oneor more MSDUs may be aggregated together to form a single large MSDU.The aggregated MSDU may be placed into a single MPDU. The single MPDUmay include a single MPDU header and a single FCS. The entire MSDU beretransmitted, for example, when the FCS of the MPDU fails.

In MPDU aggregation, one or more MPDUs may be aggregated to form asingle PSDU, where each MPDU may include may include a separate MPDUheader and a separate FCS. Some FCSs may pass FCS checking and someother FCSs may not. For the FCSs that do not pass the FCS checking, thereceiver may ask for retransmission of the corresponding MSDUs. A MPDUdelimiter may be used to separate adjacent MPDUs

For MPDU aggregations, a single PSDU may be encoded with a singleencoder, using a single interleaver. The single PSDU may be punctured,e.g., using a single puncturing pattern, and may be mapped, e.g., usinga single constellation. As illustrated in FIG. 14, one or more PSDUs maybe aggregated together.

After the PHY preamble and the legacy SIG period (L-SIG), multiple PSDUsmay be transmitted one after another, with each PSDU preceded by its HEWSIG segment and a different user-dependent sequence (US). Theuser-dependent sequence may be used to signal the user for which a PSDU(e.g., the following PSDU) may be intended. The corresponding receivermay detect its sequence, for example, by using a correlator, and mayproceed to receiving the corresponding HEW SIG period and PSDU.

The HEW SIG may be received with an error. For example, in a PSDUaggregation without the user-dependent sequence before the HEW SIG, ifone HEW SIG is received in error, the following user may not be able tofigure out where his own PSDU may start and thus may not be able toreceive its own PSDU. As described herein, this problem may be solved byintroducing the user-dependent sequence, where a following user may beable to figure out where its own PSDU starts, even when an earlieruser's HEW SIG may be received in error. Each user may not need todetect and decode other user's SIG field in order to detect and decodeits own information data.

FIG. 15 illustrates an example of an A-PSDU SIG. As illustrated in FIG.15, an A-PSDU SIG field may be introduced in the beginning of the framethat may comprise the starting point for each PSDU within the frame. Ifthe A-PSDU SIG field is received, the STA may be able to find its ownPSDU irrespective of how other PSDUs may be transmitted.

Instead of signaling the redundancy version in the MAC header, atransmitter may signal the RV by using one or more (e.g., different)sequences in the user-dependent sequence. For example, if each user hasup to three redundancy version in the encoding/puncturing process, eachuser may be allocated three unique sequences. A receiver, upon detectingthe sequence may identify whether the sequence belongs to the receiver.If the sequence belongs to the receiver, the receiver may determinewhich redundancy version may be used for the PSDU transmission.

As illustrated in FIG. 16, the transmitter may start an A-PSDUtransmission including one or more PSDUs. Each of the PSDU may beencoded separately. The MAC header of each individual PSDU may include ahigh efficiency WiFi (HEW) control field, which may include a FECredundancy version (RV) information subfield. The redundancy version(RV) information subfield may indicate to the receiver which redundancyversion of the encoder output is being used for the current PSDU. Thereceiver may use RV for decoding. The AP may use different RVs to encodeand/or puncture different PSDUs. The RV information may be indicated inthe HEW SIG field.

Upon receiving the A-PSDU packet, each receiver may send an ACK frame.The ACK frames may be sent one after another, or sent together, ifmultiple ACK transmission is enabled. The receiver may clearlyacknowledge correct reception of the PSDU, e.g., by setting ACK/RV equalto 1, e.g., if the user's PSDU is correctly received. The receiver mayrequest re-transmission of the same PSDU using a same RV or a differentRV, e.g., if the user's PSDU is not correctly received. Upon receivingthe ACK/RV frame, the transmitter may re-transmit the incorrectlyreceived PSDUs using a same or a different RV.

One or more parity matrices (e.g., used for current 802.11 systems) maybe defined for rate 1/2, 2/3, 3/4 and 5/6. These codes may not berate-compatible. Rate compatible LDPC codes may be obtained bypuncturing a base quasi cyclic parity matrix. Different code rates maybe obtained by changing the size of the circulants. An interleaver maybe used to improve performance.

If an interleaver is used, it may be formed based on the puncturingorder. The coded sequence may be interleaved and the redundancy versionmay be defined based on interleaved and coded sequence. If Interleaveris not used, the order of bit puncturing may be designed to achievebetter error correction performance in average for each of the code 4rates (e.g., 1/2, 2/3, 3/4 and 5/6) for each size (e.g., 648, 1296 and1944 bits). The redundancy version may be defined based on thepuncturing order.

One or more code-rates may be obtained by methods defined for turbocodes. For example, Mother 1/3 LDPC code may be is defined, which mayinclude 1/3 systematic (S) bits and 2/3 parity bits. The parity bits maybe divided in two parts, e.g., a part P1 of 1/3 bits, and a part P2 of1/3 bits. The S, P1, and P2 bits may be interleaved using aninterleaver. For example, block interleaver or other interleavers may beused. The interleaving may result in

(S),

(P1), and

(P2) as outputs. The resulting

(S),

(P1), and

(P2) outputs may and put it in a circular buffer. The outputs

(P1) and

(P2) may be interlaced. A starting point (e.g., different startingpoint) may be used to read from the circular buffer. This may indicatedifferent redundancy versions.

Using the same base code for 1/3 LDPC, different code rates may begenerated. Any other rate may be used for mother code. Changing the ratemay change the number of parity bits and the length of circular buffer.

In case the QC base matrix or circular buffer is used to generaterate-compatible LDPC, the payload may be divided in to one or morecode-words, e.g., by using an algorithm (e.g., provided in IEEE802.11n/ac standard).

Single payload may be divided into one or more LDPC codewords. When theFCS of the MAC frame fails, it may not mean that each of the code-wordsof LDPC failed. If during the ACK/NACK receiver signals, whichcode-words were decoded successfully, overhead of transmitting themagain may be saved. Parity structure of LDPC may be used to check thecodewords that may be decoded successfully. Same or different RVIDs maybe used for retransmission of the multiple code-words. The RVIDs may besignaled in the SIG field as described herein. The RVIDs may be part ofMAC header.

LDPC for frame aggregation may be provided. LDPC codes may be used inconjunction with the PSDU frame aggregation as described herein. PSDUfor each user may be coded with LDPC with same or different redundancyversion. RVID used for each PSDU may be included in A-PSDU SIG field.RVID may be signaled (e.g., implicitly) using one or more user-dependentsequences (US) for each RVID and/or each PSDU.

One MAC frame with one or more LDPC codewords may be provided. A MACframe may be encoded with one or more LDPC codewords (e.g., three LDPCcodeword lengths are specified in 802.11ac). At the decoder whether theLDPC code is decoded successfully may be known as the LDPC is a paritycoding scheme. It may be possible to successfully decode one or more ofthe LDPC codewords, e.g., even if the final FCS may fail. A HARQretransmission may be designed in such a way that the correctly decodedpart of the frame may not be retransmitted.

FIG. 16 illustrates an example of an HARQ retransmission with partialLDPC codewords used from the first transmission. As illustrated in FIG.15, the original MPDU, which may be composed of MAC header, MAC body,and FCS field, may be encoded with two LDPC codewords. The MAC headermay be encoded in the first LDPC codeword, LDPC1. The PPDU may betransmitted to a receiver. The receiver may detect the preamble and SIGfield correctly, and may decoded LDPC1 successfully, but the final FCSmay fail, e.g., if LDPC2 may not be decoded correctly.

The receiver may retrieve MAC header information from LDPC1, and mayfeedback a special ACK fame to the transmitter, asking the transmitterto retransmit the LDPC2. The transmitter may acquire the media again andmay perform the transmission to the receiver. The transmitter may encodea new MAC header with new data to LDPC3 and may concatenate LDPC2 as anew PPDU and transmit it to the receiver.

The MAC header may comprise information for HARQ, which may comprise oneor more of the following: TX MAC address, RX MAC address, HARQ processID for current transmission, HARQ process ID for retransmission, LDPCcodeword index for retransmission, LDPC codeword index for currenttransmission, LDPC codeword lengths, etc. The LDPC codeword index forretransmission may be used to indicate the location of the LDPCcodeword(s) in the previous HARQ transmission. LDPC codeword index forcurrent transmission index may be used to indicate the location of theLDPC codeword(s) in current transmission. This index may be used by theACK frame following this transmission to signal which LDPC codeword maybe retransmitted. Retransmission indication for each LDPC codewordsfield may indicate whether the LDPC codeword is for retransmission ornew transmission. LDPC codeword lengths field may indicate the codewordlength of each LDPC codeword other than the first one. The first LDPCcodeword length may be indicated in the SIG field.

What is claimed is:
 1. A method for use in a station (STA), the methodcomprising: receiving, from another STA, a first transmission thatincludes a first data packet; and sending, based on decoding of thefirst data packet, to the another STA, a second transmission thatincludes an aggregated packet being different than the first datapacket, wherein the aggregated packet includes at least one of anacknowledgement (ACK), a negative acknowledgement (NACK), or a seconddata packet.
 2. The method of claim 1, wherein the second transmissionis sent after determining that the first transmission is intended forthe STA and the decoding of the first data packet failed.
 3. The methodof claim 1, wherein the first transmission further comprises anindication of a number of times that the first data packet has beentransmitted.
 4. The method of claim 1, further comprising: receiving aNACK from the another STA, wherein the received NACK relates to a seconddata packet sent in the second transmission; and sending a thirdtransmission comprising a second aggregated packet, wherein the thirdtransmission uses a redundancy version.
 5. The method of claim 4,further comprising: maintaining a counter associated with a HybridAutomatic Repeat Request (HARQ) process related to the thirdtransmission; and when an ACK or a NACK has not been received before thecounter expires, retransmitting the redundancy version of the thirdtransmission.
 6. The method of claim 1, wherein one or more of aTXVector or an RXVector used by the STA include at least one of: a HARQtransmission parameter, a HARQ type parameter, a redundancy versionparameter, or a HARQ process ID.
 7. The method of claim 1, wherein thefirst transmission and the second transmission are IEEE 802.11 messages.8. The method of claim 1, wherein the second transmission furthercomprises an indication of a number of times that the second data packethas been transmitted.
 9. A station (STA) comprising: a receiverconfigured to receive, from another STA, a first transmission thatincludes a first data packet; and a transmitter configured to send,based on decoding of the first data packet, to the another STA, a secondtransmission that includes an aggregated packet being different than thefirst data packet, wherein the aggregated packet includes at least oneof an acknowledgement (ACK), a negative acknowledgement (NACK), or asecond data packet.
 10. The STA of claim 9, wherein the secondtransmission is sent after determining that the first transmission isintended for the STA and the decoding of the first data packet failed.11. The STA of claim 9, wherein the first transmission further comprisesan indication of a number of times that the first data packet has beentransmitted.
 12. The STA of claim 9, wherein the receiver is furtherconfigured to receive a NACK from the another STA, wherein the receivedNACK relates to a second data packet sent in the second transmission,and wherein the transmitter is further configured to send a thirdtransmission comprising a second aggregated packet, wherein the thirdtransmission uses a redundancy version.
 13. The STA of claim 12, furthercomprising: a processor configured to maintain a counter associated witha Hybrid Automatic Repeat Request (HARQ) process related to the thirdtransmission, wherein when an ACK or a NACK has not been received beforethe counter expires, the transmitter is configured to retransmit theredundancy version of the third transmission.
 14. The STA of claim 9,wherein one or more of a TXVector or an RXVector used by the STA includeat least one of a HARQ transmission parameter, a HARQ type parameter, aredundancy version parameter, or a HARQ process ID.
 15. The STA of claim9, wherein the first transmission and the second transmission are IEEE802.11 messages.
 16. The STA of claim 9, wherein the second transmissionfurther comprises an indication of a number of times that the seconddata packet has been transmitted.